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Streszczenie 


Praca ma na celu rozwój metodyki planowania zachowań botów z wykorzystaniem 
programowania w logice. Znane są podejścia w których programowanie w logice jest 
wykorzystywane do sterowania robotami lub też botami w symulowanym środowisku gry. 
Jednak zastosowanie tego podejścia w komercyjnej produkcji napotyka na szereg trudności 
praktycznych i koncepcyjnych. W pracy został przedstawiony sposób realizacji bota 
pozwalający na 
— wielokrotne użycie zachowań botów, które zostały raz wytworzone, w innych grach FPS, 
— dostosowywanie raz stworzonych botów do nowych warunków (np. przez wprowadzenie 

nowej planszy lub modyfikacji gry). 

Koncepcja realizacji bota, przedstawiona w pracy, została zweryfikowana w praktyce w 
grze Counter-Strike. Jest to gra, która posiada dużą liczę skomplikowanych zasad, które 
tworzą bardzo realistyczną rozgrywkę. Sama gra jest jedną spośród wielu modyfikacji gry 
Half-Life. Jest to najpopularniejsza spośród modyfikacji, skupiająca środowisko fanów, którzy 
przygotowują regularnie dodatkową zawartość do gry (najczęściej plansze). Uzyskana w ten 
sposób wielość wariantów gry pozwala na zaprezentowanie w pełni potencjału rozwiązania 
będącego przedmiotem rozważań w tej pracy. Counter-Strike jako gra wieloosobowa 
posiada również wiele implementacji botów, z czego znaczna ich część jest udostępniana 
jako oprogramowanie open-source, co umożliwia porównanie z istniejącymi rozwiązaniami, 


realizację koncepcji rozprawy doktorskiej oraz przeprowadzenie eksperymentów. 


Słowa kluczowe: systemy agentowe, gry komputerowe, symulacja, planowanie, wnioskowanie, 


programowanie w logice, sztuczna inteligencja 


Abstract 


The goal of this work is to develop the behavior planning methodology with application of 
the logic programming. There are known approaches where the logic programming was used 
to control real-world robots or bots in a simulated game environment. In spite of that fact, 
the application of this approach in commercial production faces series of both practical and 
conceptual difficulties. In this work there was shown a bot design which enhances 
— reusability of once created bot behaviors in other FPS video games, 

— adaptation of bots created with this methodology to new conditions (eg. new maps or game 
mods). 

The bot concept presented in this work was verified in practice in Counter-Strike game. 


The game contains a lot of complicated rules, which compose a very realistic gameplay. The 


game itself is one among many of Half-Life modifications. This is the most popular of the 
modifications, having a huge fan community, which crafts additional game content regularly 
(mostly game maps). The variety of game configurations allows to fully present the potential of 
the solution, which is a subject of considerations of this thesis. Counter-Strike as multiplayer 
game has many bot implementations. Many of those are publicly available as an open-source 
software, what allows for comparison with existing solutions, completion the thesis concept and 


running the experiments. 


Keywords: multiagent systems, computer games, simulation, planning, reasoning, logic 


programming, artificial intelligence 
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Skorowidz nazw, skrótów i symboli 


Nazwy własne: 

— (Counter-Strike, gra komputerowa typu FPS. Jest ona najpopularniejszą modyfikacją gry 
Half-Life. 

— Firearms, gra komputerowa typu FPS. Jest ona modyfikacją gry Half-Life. 

— GeoMod, biblioteka stosowana w grach symulacyjnych, dostarczająca funkcji do 
modyfikowania terenu w środowisku gry. 

— Half-Life, gra komputerowa typu FPS udostępniająca rozbudowane SDK do tworzenia 
modyfikacji. 

— MetaMod, modyfikacja gry Counter-Strike pełniąca funkcję menadżera wtyczek do gry. 

— Steam, usługa gier online; rozbudowany następca usługi WON. 

— deathmatch (również, free for all) - tryb rozgrywki w grach wieloosobowych, w którym 
celem gracza jest wyeliminowanie innych uczestników rozgrywki. 

Skróty: 

— ABI - (ang. Application Binary Interface), tutaj: zespół reguł i ustaleń, które decydują o 
współpracy między skompilowanymi komponentami aplikacji, tj. pliku wykonywalnego i 
bibliotek współdzielonych. 

— AMX - (ang. Abstract Machine eXecutive), maszyna wirtualna, zaprojektowana do 
osadzania w aplikacjach i pozwalająca na uruchamianie prekompilowanych skryptów. 
Znana jest przed wszystkim z użycia w modyfikacji gry Counter-Strike, AMX Mod, która 
pozwala na tworzenie skryptów uruchamianych na serwerze gry. 

— API - (ang. Application Programming Interface), zespół reguł i ustaleń na poziomie kodu 
źródłowego aplikacji, które decydują o współpracy między jej komponentami. 

— BDI- (ang. Beliefs, Desires, Intentions), architektura w systemach agentowych. 

— CML - (ang. Cognitive Modelling Language), język do definiowania zachowań postaci 
stosowany w animacja komputerowych. 

— DLL - (ang. Dynamic Link Library), biblioteka współdzielona w środowisku Microsoft 
Windows 

— EC2 - (ang. Elastic Computing Cloud), chmura obliczeniowa udostępniona przez firmę 
Amazon; w tej rozprawie wykorzystana do przeprowadzenia eksperymentów. 

— E[POD] - (ang. Extended [Ping of Death]), bot do gry Counter-Strike. Kod źródłowy tego 


bota wykorzystano do stworzenia bota opisanego w niniejszej pracy. 


— FPP - (ang. First Person Perspective), rodzaj gry komputerowej, w której gracz kieruje 
postacią w wirtualnym Świecie, widząc Świat z jej perspektywy. 

— FPS - (ang. First Person Shooter), gra akcji typu FPP, w której gracz uczestniczy w walkach 
z użyciem broni palnej. 

— GRL - (ang. General Robotic Language), język do definiowania zachowań robotów. 

— HP - (ang. Hit Point, punkty życia), jednostka określająca ile postać w grze komputerowej 
jest w stanie wytrzymać uszkodzeń zanim zostanie wyeliminowana. 

— HPB - (ang. High Ping Bastard), nazwa własna bota w grze Half-Life. W środowisku graczy 
gry Half-Life bot ten jest określany "ojcem wszystkich botów”, ponieważ historycznie 
powstał on jako pierwszy i kolejne boty dla gry Half-Life powstawały poprzez modyfikacje 
jego kodu źródłowego. 

— «Bot, nazwa własna bota stworzonego przez autora niniejszej rozprawy w celach 
naukowych. 

— MMO - (ang. Massively Multiplayer Online), rodzaj gry wieloosobowej charakteryzujący 
się dużą liczbą graczy jednocześnie uczestniczących w rozgrywce. 

— OGC - (ang. Online Game Cheat), modyfikacja klienta gry Counter-Strike pozwalająca 
graczowi na łamanie reguł gry (np. widzenie przez Ściany). 

— PCG - (ang. Procedural Content Generation), zawartość multimedialna gry, która została 
wygenerowana za pomocą algorytmów, nie będąca bezpośrednim dziełem człowieka. 

— POD - (ang. Ping Of Death), nazwa własna bota dla gry Counter-Strike. 

— POI - (ang. Point of Interest), punkt w przestrzeni, który może być warty uwagi. 

— RTS - (ang. Real-Time Strategy), typ strategicznej gry komputerowej, w której gracz kieruje 
armiami złożonymi z wielu jednostek. 

— RACC - (ang. Rational Autonomous Cybernetic Commandos), biblioteka dostarczająca 
warstwy abstrakcji pomiędzy środowiskiem gry, a kodem wykonywalnym bota, w celu 
dokładnego symulowania percepcji postaci kontrolowanych przez bota. 

— SDK - (ang. Software Development Kit), zestaw narzędzi i bibliotek niezbędny 
programistom do tworzenia aplikacji uruchamianych na danej platformie, np. modyfikacji 
gry komputerowej, które korzystają z jej silnika. Zwykle w skład tego zestawu wchodzą 
również dokumentacja oraz przykładowe kody źródłowe. 

— STL - (ang. Standard Template Library) biblioteka C++ zawierająca algorytmy, kontenery, 
iteratory oraz inne konstrukcje w formie szablonów, gotowe do użycia w programach. 

— SWI- (hol. Sociaal-Wetenschappelijke Informatica, Informatyka w naukach społecznych), 
dawna nazwa jednostki naukowej na Uniwersytecie Amsterdamskim, skąd wywodzi się 
SWI-Prolog — implementacja języka Prolog. 


— VoIP - (ang. Voice over IP), protokół komunikacji głosowej za pośrednictwem protokołu IP. 


— VIP - (ang. Very Important Person), w grze Counter-Strike, postać sterowana przez jednego 
w graczy w rozgrywce drużynowej na mapie typu AS. 

— WON - (ang. World Opponent Network), nieistniejąca już usługa gier online, używana 
m.in. w grze Half-Life, udostępniała ona informacje o serwerach online. 

— WON2 - (patrz: WON), kopia usługi WON stworzona przez środowisko fanów gry 
Counter-Strike jako odpowiedź na zamknięcie usługi WON. 

Symbole i oznaczenia: 

— A -zbiór akcji możliwych do podjęcia w środowisku przez agenta. 

— allcost/1 - predykat, który służy jako motywacja, która jest zawsze spełniona. 

— M- zbiór akcji złożonych; są to jednostki organizujące akcje A w struktury, które są prostsze 
do zastosowania przy podejmowaniu decyzji przez agenta. 

— action - rodzina funkcji modelujących decyzje agenta. Parametry wejściowe mogą się 
różnić w zależności od sposobu funkcjonowania agenta, jednak wynikiem tej funkcji w 
każdym przypadku jest akcja, którą może wykonać w Środowisku agent. 

— B - zbiór agentów działających w środowisku. 

— env - funkcja opisująca zmiany środowiska pod wpływem decyzji pojedyńczego agenta. 


— G- przestrzeń celów dla akcji. 











— I - przestrzeń stanów wewnętrznych agenta. 





— M -przestrzeń motywacji dla akcji. 

— next - funkcja modelująca zmiany stanu wewnętrznego bota pod wpływem obserwacji stanu 
środowiska. 

— O -zbiór obserwacji stanu środowiska gry. 

— see - funkcja modelująca percepcję agenta w środowisku gdzie działa jeden agent. 

— see, - odwzorowanie między stanem środowiska a opisującymi je faktami. 

— see, - funkcja modelująca percepcję agenta w środowisku gdzie działa wielu agentów. 

— t, - czas na podjęcie decyzji, w środowisu epizodycznym, które aproksymuje środowisko 
czasu rzeczywistego. 


— U -zbiór stanów środowiska, w którym działają agenty. 


1. Wprowadzenie 


Rozdział ten ma na celu prezentacje ogólnych informacji na temat sztucznej inteligencji, 


gier komputerowych i relacji pomiędzy nimi. 


1.1. Sztuczna inteligencja jako dyscyplina naukowa 


Inteligencja jest pojęciem trudnym do precyzyjnego zdefiniowania. Jego rozumienie 
może być bardzo subiektywne i podatne na kontekst, w którym są prowadzone rozważania. 
Niezaprzeczalnym faktem jest, że mianem istot inteligentnych zwykło się nazywać 
przedstawicieli gatunku Homo Sapiens. Jednak już odpowiedzi na pytania, czy inteligencja 
przysługuje jedynie człowiekowi i czy może być cechą jedynie organizmów żywych, zależą 
mocno od przyjętej definicji. 

Według koncepcji rozwoju intelektualnego [44], inteligencja jest zaawansowaną formą 
adaptacji biologicznej, wzbogaconą o ustrukturalizowane procesy poznawcze. Takie 
rozumienie inteligencji zostało zaproponowane przez psychologa Jeana Piageta, którego 
badania były poświęcone badaniu inteligencji w rozwoju dzieci. 

Psycholog Charles Spearman zaproponował inne spojrzenie na inteligencję. Według jego 
czynnikowej teorii inteligencji [54], za inteligencję odpowiadają dwa czynniki: ogólny oraz 
specyficzny. Czynnik ogólny jest związany z operowaniem na pojęciach abstrakcyjnych, 
wnioskowaniem, dostrzeganiem relacji i zależności. Natomiast czynnik specyficzny odpowiada 
za zdolności specyficzne do wykonania danego zadania. 

Psycholog William Stern podaje definicję, według której inteligencja jest zdolnością do 
adaptacji poprzez wykorzystanie procesów umysłowych [56]. Inne definicje odwołują się do 
faktu przetwarzania informacji w celu uzyskania nowych danych — w ten sposób można mówić 
o inteligencji maszyn [52]. Bardziej kontrowersyjne definicje mianem inteligencji określają 
zdolność do rozwiązywania testów na inteligencję — według takiej definicji brakiem inteligencji 
mogą odznaczać się nawet wybrani ludzie [20]. 

W wyżej wymienionych definicjach występują często razem trzy ważne atrybuty — zdolność 
adaptacji, przetwarzanie informacji i procesy myślowe. O ile fakt istnienia procesów 
myślowych jest trudny do potwierdzenia lub zaprzeczenia, to zdolność do adaptacji jest 
zjawiskiem, które poddaje się badaniom w sensie nauki Ścisłej. Ta myśl była podstawą 


dla psychologii behawioralnej [5]. Koncepcja ta nie neguje istnienia takich konstruktów 


myślowych jak emocje czy motywacje, uważa jednak je za „nienaukowe”, ponieważ ich 
istnienie trudno jest zweryfikować za pomocą nauk ścisłych. Można pójść o krok dalej i 
twierdzić, że jeśli istota wykazuje zachowania typowe dla człowieka, to nie tylko posiada 
inteligencję ludzką, ale również posiada świadomość, wręcz jest człowiekiem. Taki pogląd 
jest znany pod pojęciem funkcjonalizmu. 

Innym nurtem jest psychologia poznawcza [39], której głównym zainteresowaniem jest 
sposób funkcjonowania ludzkiego umysłu. Takie badania przeprowadza się poprzez obserwację 
zachowania człowieka w kontrolowanych warunkach i próbuje się wyjaśnić zasadność pewnych 
hipotez np. wpływu emocji na zdolności zapamiętywania. 

Brak ostrej i obiektywnej definicji pojęcia inteligencji przyczynia się do braku sztywnych 
granic sztucznej inteligencji jako dyscypliny naukowej. Ogólnie można ją scharakteryzować 
jako dział informatyki zajmujący się tworzeniem modeli zachowań inteligentnych oraz 
algorytmów i programów komputerowych, które symulują takie zachowania. W szczególności 
dotyczy to programów komputerowych, które przejawiają takie cechy jak adaptacja własnego 
działania do warunków, w których funkcjonują, możliwość podejmowania decyzji w oparciu o 
fragmentaryczne informacje lub nawet naśladowanie ludzkiego zachowania. Istnieje również 
nieco inne spojrzenie na dziedzinę sztucznej inteligencji, polegające na scharakteryzowaniu jej 
jako działu informatyki zajmującego się rozwiązywaniem problemów, które nie są efektywnie 
algorytmizowalne [12]. 

Russell i Norvig [51], dokonując próby systematyzacji badań w dziedzinie sztucznej 
inteligencji, wyróżniają cztery podejścia do jej definicji (por. tab. 1.1). Klasyfikuja 
systemy będące przedmiotem badań sztucznej inteligencji ze względu na dwa aspekty — 
działanie albo myślenie oraz sposób oceny rezultatów działania systemu — podobieństwo 
do człowieka lub racjonalność. W przypadku oceny działania systemu brana jest pod uwagę 
jakość podejmowanych decyzji, zaś w przypadku oceny myślenia — sposób uzyskania danej 


odpowiedzi przez system. 





działanie myślenie 
ludzkie | Systemy naśladujące człowieka | Systemy myślące jak ludzie 
racjonalne | Systemy postępujące racjonalnie | Systemy myślące racjonalnie 























Tablica 1.1. Różne podejścia do sztucznej inteligencji 


W myśl tej klasyfikacji, systemy myślące jak ludzie symulują funkcjonowanie ludzkiego 
umysłu, np. poprzez odtwarzanie fizjologii mózgu czy też poprzez wyodrębnienie i kodyfikację 
procesów poznawczych, które składają się na funkcjonowanie umysłu. 

Systemy, które charakteryzują się racjonalnym myśleniem, wykorzystują mechanizmy 
przetwarzania informacji właściwe istotom inteligentnym w celu uzyskania przydatnych 


wyników. Przykładem takiego mechanizmu może być dedukcja, wykorzystywana do 
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odkrywania nowych faktów w dedukcyjnych bazach danych. Najczęściej systemy myślące 
racjonalnie charakteryzują się zdolnością do postrzegania, gromadzenia wiedzy i odkrywania 
nowych informacji [65]. 

Celem systemów naśladujących działanie człowieka jest funkcjonowanie tak samo jak 
człowiek, na przykład, podejmowanie przez program komputerowy decyzji podobnych do 
tych podejmowanych przez ludzi w identycznej sytuacji [21]. W szczególności systemy te 
podejmują decyzje błędne w okolicznościach, w których człowiek podjąłby taką decyzję. 

Systemy postępujące racjonalnie wykorzystują procesy, noszące znamiona inteligencji, 
do rozwiązywania problemów decyzyjnych. Systemy takie mogą posiadać takie cechy 
jak zdolność do adaptacji do środowiska, w którym funkcjonują, czy też formułowania 
wniosków na jego temat. Od takich systemów nie oczekuje się jednak zachowania podobnego 
do zachowania człowieka, tylko spełnienia pewnego kryterium zależnego od przeznaczenia 
systemu. 

Nawet najbardziej inteligentne i wyrafinowane zachowania nie zawsze gwarantują 
osiągnięcie założonego rezultatu. Jednak uważa się, że jeżeli zachowanie jest skuteczne i 
prowadzi do celu, to jest racjonalne. Jest to pewnego rodzaju warunek wystarczający. Natomiast 
skuteczność zachowania 1 stopień osiągnięcia celu można obiektywnie mierzyć. Jest to częsta 
motywacja przy tworzeniu systemów o racjonalnym zachowaniu. 

Naśladowanie człowieka lub jego myślenia jest jednym z celów sztucznej inteligencji, 
dlatego potrzebne są kryteria służące do oceniania, w jakim stopniu taki cel został osiągnięty. 
W przypadku naśladowania ludzkiego myślenia taką rolę pełni test Turinga [59]. Ideą tego testu 
jest prowadzenie rozmowy w języku naturalnym przez sędziego z człowiekiem i komputerem. 
Rozmowa ta ma na celu poznanie „myśli” uczestnika rozmowy. Sędzia nie wie uprzednio, 
który uczestnik rozmowy jest człowiekiem, a który programem komputerowym. Jeżeli sędzia 
nie jest w stanie określić poprawnie, która strona rozmowy jest człowiekiem, to uważa się, że 
program zakończył test z wynikiem pozytywnym. Test Turinga jest kryterium subiektywnym, 
jednak przeprowadzenie go przez wielu sędziów i uśrednienie wyników pozwala na pewną 


obiektywizację wyników [37]. 


1.2. Gry komputerowe 


1.2.1. Charakterystyka gier komputerowych 


Podobnie jak pojęcie inteligencji, pojęcie gry jest bardzo szerokie. Cechą wspólną 
większości gier jest posiadanie określonego celu oraz reguł, nazywanych mechaniką gry [26]. 
Najczęściej gry maja charakter rozrywkowy, lecz wykorzystuje je się również w innych celach, 
np. szkoleniowych. Rozrywkowy charakter gier jest pojęciem trudnym do zdefiniowania. 


Podjęto jednak próby określenia czynników odpowiadającym za taki charakter gier. Według 


11 


Rogera Calloisa [8] program komputerowy może być uznawany za grę, jeżeli korzystanie z 

niego jest: 

1. dobrowolne (free) — decyzja o uczestnictwie w grze jest podejmowana przez gracza 
dobrowolnie, 

2. wyodrębnione w czasie i przestrzeni (separate in time and space) — gra odbywa się w 
wyodrębnionym czasie i przestrzeni; akcje w grze nie mają wpływu na stan gracza w 
rzeczywistym Świecie, 

3. związane z niepewnością (uncertain) — przyszły wynik rozgrywki jest nieznany dla gracza 
lub nie wynika natychmiast z reguł gry, 

4. nieproduktywne (unproductive) — granie w grę nie przynosi żadnych zysków w realnym 
świecie, 

5. kierowane zasadami (governed by rules) — omówione wyżej, 

6. pozorowane (make-believe) — scenariusz gry osadzony w innej rzeczywistości, np. bierki na 
planszy mogą symbolizować budynki, chociaż nimi naprawdę nie są. 

Należy zauważyć, że chociaż te czynniki korelują się z rozrywkowym charakterem gier, nie 
są warunkami koniecznymi do takiego charakteru np. gry hazardowe nie są nieproduktywne 
w sensie powyższej klasyfikacji. Sam Callois omawia kompromis między pozorowaniem a 
obecnością zasad na przykładzie gry w szachy. Scenariusz szachów zakłada walkę dwóch armii, 
ale, ze względu na zasady rządzące grą, częściej rozpatruje się ich logiczny charakter. Czynnik 
wyodrębnienia jest również aspektem podlegającym dyskusji. Przykładem braku takiej cechy 
są gry komputerowe, w których wirtualne przedmioty, istniejące w świecie gry, można kupić 
w sklepie, który istnieje w rzeczywistości. Taka praktyka jest stosowana np. w grze Farmville 
stworzonej przez firmę Zynga. Jest to część modelu biznesowego tej firmy. 

Istnieje tak duża różnorodność gier komputerowych, że zwykle mówi się o określonym 
gatunku gier komputerowych. Gry komputerowe w obrębie gatunku charakteryzują się 
podobną mechaniką gry lub pewnymi podobieństwami świata przedstawionego. W tablicy 1.2.1 
scharakteryzowano kilkoro przykładowych gatunków gier komputerowych, wyróżnionych na 
podstawie podobieństwa mechaniki gry. 

Przedstawione kategorie to zaledwie mały fragment wszystkich znanych gatunków gier 
komputerowych. Klasyfikacja ta w dodatku nie jest Ścisła, bo występują również gry łączące 
w sobie elementy różnych gatunków, np. gatunek MMO odnosi się reguł gry związanych ze 
współuczestnictwem innych graczy w rozgrywce, gatunki FPP i TPP odnoszą się do sposobu 
prezentacji Świata przedstawionego, natomiast RTS i RPG odnoszą się do mechaniki gry. Z tego 
powodu pojedyncza gra może mieć cechy wielu gatunków. Popularnym przykładem jest gra 
World of Warcraft, która należy ona jednocześnie do gatunków MMO i RPG. Jeżeli powstaje gra 
o nowej mechanice i odnosi sukces, to inni producenci chętnie adaptują pomysł. W przypadku 


gry World of Warcraft to zjawisko było tak silne, że można mówić o gatunku MMORPG. 
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Gatunek Charakterystyka 
Do tej kategorii klasyfikują się komputerowe adaptacje gier 








Gry planszowe rozgrywanych turowo za pomocą planszy i bierek, np. szachy 
lub hex. 

Gy krate Komputerowe adaptacje gier rozgrywanych za pomocą talii kart, 
np. poker. 





Gry strategiczne rozgrywane w czasie rzeczywistym (w 


R Ti t EGE . 
ae WEE "oMaRY przeciwieństwie do gier turowych). Gracze tworzą dowodzą 











(RES) armiami, które walczą ze sobą. 
Ogół gier w których gracz widzi świat gry z perspektywy postaci, 
First Peron którą kieruje. Często gry te polegają na walce z wieloma 
Perspective (FPP) przeciwnikami za pomocą broni palnej. W takim przypadku 
mówi się o gatunku First Person Shooter (FPS), który jest 
podgatunkiem FPP. 
Third o" Ogół gier komputerowych, w których gracz widzi Świat 
Perspective (TPP) przedstawiony za pomocą kamery podążającej za postacią 
kierowaną przez gracza. 
W tym gatunku gracz obserwuje kierowaną przez siebie postać 
Plaiformer z boku w świecie gry, który jest dwuwymiarowy. Gracz moze 


poruszać się w nim w poziomie — chodząc, oraz pionowo — 
skacząc. 

Jest to bardzo popularny gatunek gier komputerowych. Gracz 
odgrywa pewną role w świecie gry. Rozgrywka charakteryzuje 
się bogatą fabułą i możliwościami zmieniania jej przebiegu 
poprzez decyzje podejmowane przez postać w świecie gry. 
Częścią mechaniki zaczerpniętą z „książkowej wersji” tych gier 
jest występowanie atrybutów postaci (np. siła fizyczna) i 
możliwości ich rozbudowywania w trakcie rozgrywki. 

Massively Multiplayer | Gry prowadzone za pośrednictwem internetu, w których może 
Online (MMO) uczestniczyć wielu graczy równocześnie. 





Role Playing Game 
(RPG') 

















Tablica 1.2. Przykłady gatunków gier komputerowych. 


Ze względu na zróżnicowanie gier komputerowych, różnice w celach gry i mechanice, 
wymagania stawiane przed twórcami algorytmów sztucznej inteligencji w każdym gatunku 
gier będą inne. Co więcej, często są inne w każdej pojedynczej grze. Niekiedy zastosowanie 
algorytmów sztucznej inteligencji, w celu zapewniania postaci sterowanych przez komputer, nie 
jest w ogóle konieczne. Tak może być w grach typu MMO, gdy każda z postaci uczestniczących 
w rozgrywce jest sterowana przez człowieka. 

Obecnie nie jest znany algorytm, który byłby zdolny grać w dowolną grę. Jednak 
prowadzone są prace w ramach nurtu General Game Playing [19], polegającego na tworzeniu 
algorytmów, zdolnych do gry więcej niż w jedną grę. Istnieją pewne postępy w tej dziedzinie 


jeżeli chodzi o gry planszowe. W ramach tego nurtu badań zakłada się, że znajomość 
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zasad gry, opisanych np. za pomoca jezyka GDL’, wystarczy do efektywnego prowadzenia 
rozgrywki poprzez algorytm „ogólnego przeznaczenia”. Przypomina to podejście, w którym 
wnioskowanie w logice predykatów jest realizowane poprzez odpowiedni system, a konkretny 
problem definiowany jest poprzez podanie predykatów go opisujących. 

Gry komputerowe są oprogramowaniem mającym na celu dostarczenie swoim 
użytkownikom rozrywki. Ich posiadanie jest zatem opcjonalne, nie są produktem pierwszej 
potrzeby (tzw. nice-to-have). Dlatego, aby stworzyć produkt, który będzie odpowiadał 
oczekiwaniom graczy, ważne jest zrozumienie, dlaczego grają oni w gry komputerowe. 
Ich potrzeby przekładają się na wymagania projektowe, a te natomiast na wymagania dla 
poszczególnych komponentów, z których zbudowana jest gra — w tym algorytmów sztucznej 
inteligencji. Nick Yee [68] przeprowadził badania motywacji graczy gry World of Warcraft. 
Wyróżnił on motywacje, które można podzielić na trzy kategorie: związane z osiągnięciami, 
społecznością oraz immersją w grze. 

Motywacje związane z osiągnięciami w Świecie gry to możliwości awansowania postaci, 
zdobywania punktów bądź przedmiotów, konkurowania z innymi graczami oraz satysfakcji ze 
zwycięstwa nad nimi. Motywacje związane ze społecznością w grze komputerowej polegają 
na możliwościach udzielania się towarzysko w Świecie gry poprzez rozmowy i interakcje z 
innymi graczami (np. pomaganie im w Świecie gry). Są to również możliwości wyrażenia 
siebie poprzez wygląd postaci w Świecie gry i decyzje o jej zachowaniu. Motywacje związane 
z immersją dotyczą utożsamiania się gracza ze światem przedstawionym w grze. Jest to 
ciekawość tego Świata, chęć jego eksploracji i poznawania fabuły gry. Jest to przykład cechy 
określanej przez Calloisa jako pozorowanie (make believe). 

Zjawisko immersji jest również terminem funkcjonującym w sztuce współczesnej [43]. 
Polega na „wchłanianiu” widza przez „rzeczywistość elektroniczną. Chęć doświadczenia 
odmiennej „rzeczywistości? jest ważną motywacją, dla której gracze sięgają po gry 
komputerowe. „Rzeczywistość ta nie musi być całkowicie fikcyjna — niekiedy „zmiana 
rzeczywistości” może polegać na wcieleniu się przez gracza w postać o innych cechach niż jego 
własne w świecie, który przypomina świat znany graczowi [40]. Na gry o silnie immersyjnym 
charakterze można patrzeć jak na symulatory rzeczywistości, np. gra komputerowa Emergency 
jest symulatorem akcji ratunkowych przeprowadzanych przez straż pożarną, policję i służby 
medyczne [28]. 

W celu osiągnięcia dobrego stopnia immersji w grach symulacyjnych, obraz przez nie 
prezentowany powinien być stwarzać wrażenie autentycznego, tzn. zachowanie postaci 
powinno być adekwatne do ich miejsca i roli. Należy zauważyć, że chodzi tu o wywołanie 
u gracza odpowiedniego wrażenia, co jest odczuciem bardzo indywidualnym. Istnieje efekt 


nazywany podstawowym błędem atrybucji, w dziedzinie sztucznej inteligencji jest on nazywany 


2 ang. Game Description Language 
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efektem ELIZA [13]3. Polega on na wyjaśnianiu obserwowanego zachowania w kategoriach 
przyczyn wewnętrznych przy ignorowaniu wpływu przyczyn zewnętrznych. Występowanie 
tego efektu jest ważne w zjawisku immersji. Gracz będzie tłumaczył wrażenie autentycznego 
zachowania symulacji jej faktyczną autentycznością. Dla projektantów wirtualnych postaci, 
które biorą udział w symulacji, efekt ELIZA oznaczać będzie, że zachowanie ich wytworów 
może być całkowicie dyktowane scenariuszem, a mimo to w dalszym ciągu może sprawiać 
na graczu wrażenie zachowań inteligentnych. W przypadku pojawienia się możliwości 
podejmowania decyzji, przede wszystkim będzie liczyło się wrażenie wywierane na graczu, 
a nie sposób, w jaki te decyzje są podejmowane. W kontekście klasyfikacji Russela i Norviga, 
zadanie określania sposobu zachowania symulowanych postaci mogłoby się kwalifikować 
do kategorii „systemów naśladujących zachowanie człowieka”. Warto zauważyć, że jest 
to pojęcie dość umowne, gdyż inspiracją dla sztucznej inteligencji są zachowania ludzkie, 
natomiast w grach komputerowych sztuczna inteligencja symuluje zachowanie również innych 
humanoidów, np. orków, od których nie oczekuje się zbytniej mądrości”. Wysiłki twórców 
gier komputerowych koncentrują się na tworzeniu postaci, które zachowują się realistycznie 1 
odpowiednio do powierzonej im roli, wynikającej ze Świata przedstawionego gry. 

Ludzkie intuicje oparte są na doświadczeniach ze Świata rzeczywistego [15] lub innych 
gier, w które gracz grał. Znajomość tych intuicji jest wykorzystywana w celu takiej 
prezentacji Świata gry, aby gracz mógł cieszyć się rozgrywką w tym wirtualnym świecie, 
bez zbędnych wstępnych przygotowań w postaci przyswajania dodatkowych informacji o nim 
[50]. Należy pamiętać, że symulowany świat może rządzić się innymi prawami, np. na 
skutek zaawansowanej technologii lub „czarów” postacie mogą widzieć przez Ściany. Jeśli 
gracz zostanie nieumiejętnie wprowadzony w taki świat, to może towarzyszyć mu podczas gry 
uczucie niepewności. Im bardziej nietypowy Świat, tym więcej czasu potrzeba na jego pełne 
zrozumienie. 

Budowanie wrażenia inteligentnego zachowania wyłącznie za pomocą scenariusza nie 
ma wiele wspólnego z procesami inteligencji. Nie zachodzą wtedy zjawiska adaptacji 
zachowania i analizowania informacji przez postacie w grze. Jednak gracz może odnosić takie 
wrażenie, bo zarówno sama zmiana środowiska, jak i adaptacja zachowania postaci do tej 
zmiany, w przypadku posługiwania się scenariuszem są wyreżyserowane. Takie rozwiązania 
scenariuszowe spotyka się w grach z gatunku przygodowych”, w których wątek fabularny jest 
szczególnie mocno rozbudowany. 

Tworzenie scenariusza jest procesem czasochłonnym, gdyż projektant musi podejmować 
decyzje dla każdej postaci w grze. W przypadku złożonych planszy w grze, z dużą liczbą 


postaci, jak np. w grach wojennych, jest to niewykonalne. W takim wypadku algorytmy 


3 
4 


nazwa ta pochodzi od programu komputerowego służącego do prowadzenia dialogów z użytkownikiem 
nota bene, to nie czyni łatwiejszym zadania tworzenia algorytmów do sterowania ich zachowaniem 
> ten fakt jest szczególnie cenny przy tworzeniu sequeli i serii gier 
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sztucznej inteligencji znajdują zastosowanie w przypadku podejmowania decyzji na bieżąco 
przez postacie. Zastosowanie sztucznej inteligencji do sterowania postaciami wcale nie oznacza 
rezygnacji z odgrywania przez te postacie scen dyktowanych przez scenariusz. Przykładem 
takiego rozwiązania jest system Virtual Theatre, który zastosowano w grze przygodowej Lure 
of the Temptress w 1988 roku. Postacie w tej grze, oprócz pełnienia funkcji fabularnych, 
dyktowanych scenariuszem, starały się wypełniać zadania niezwiązane bezpośrednio z celami 
gracza, np. robiły zakupy na targu. Pozwoliło to na uzyskanie społeczności wirtualnych postaci, 
która żyje własnym życiem, i poprawienie wrażeń z rozgrywki. 

Dzięki stosowaniu sztucznej inteligencji w grach możliwe jest również tworzenie otwartego 
świata gry. Jest to taki świat, po którym gracz może nieustannie podróżować, cały czas 
odkrywając nowe miejsca i postacie. Jest to technika zaliczana do kategorii proceduralnie 
generowanej zawartości — PCG (Procedural Content Generation) [25]. Świat taki opisany jest 
poprzez sposób jego konstrukcji, np. zestaw procedur i reguł. Fragmenty Świata gry, które są 
istotne dla rozgrywki w danym momencie, są tworzone poprzez wykonanie ich konstrukcji na 
podstawie podanego opisu [24]. W takim Świecie, wrażenia inteligentnych zachowań nie da się 
osiągnąć wyłącznie za pomocą scenariusza. Konieczne jest zastosowanie algorytmów sztucznej 


inteligencji do sterowania postaciami w Świecie gry. 


1.2.2. Charakterystyka gier FPS jako przedmiotu badań 


Gry typu FPP (First Person Perspective) są grami, które maja bardzo immersyjny charakter, 
ponieważ pozwalają graczowi oglądać Świat niejako własnymi oczami. Dokładnie z takiej 
samej perspektywy człowiek ogląda Świat rzeczywisty. Projektowanie świata gry FPP wymaga 
drobiazgowego przygotowania, żeby gra wyglądała wiarygodnie i atrakcyjnie. Tego typu 
sposób przedstawiania Świata gry jest używany w grach, których celem jest osiągnięcie dużego 
stopnia immersji. Np. po gry typu survival horror sięga się aby doświadczyć poczucia 
strachu. Jeżeli zachodzi zjawisko immersji, to zagrożenia dla postaci w grze, są przez gracza 
interpretowane jako zagrożenia dla jegp samego, co może wywoływać u niego strach. 

W niniejszej pracy będzie omawiana metodyka definiowania zachowania postaci w grach 
na przykładzie gier FPS ze względu na ich mechanikę oraz sposób prezentacji Świata 
przedstawionego. W takiej grze na postacie, które istnieją w rzeczywistości wirtualnej, można 
patrzeć jak na agentów w pewnym środowisku. Agenci są bytami, które działają w środowisku, 
mogą w nim wykonywać działania i uzyskują informacje o nim za pośrednictwem sensorów 
(rys. 1.1). 

W grze FPS postacie sterowane przez komputer są zwyczajowo nazywane przez graczy 
„botami”. Jednakże nazwy programów komputerowych sterujących zachowaniem postaci 
w grze komputerowej są również nazywane „botami”, np. „bot E/POD]”’. W tej pracy 


autor przyjął konwencję, że mianem bota jest określana postać sterowana przez komputer. 
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Natomiast program komputerowy, który jest wykorzystywany do sterowana zachowaniem bota 
jest określany jako „sterownik bota” lub „algorytm sterowania botem”. Słowo „postać w grze” 
oznacza bota lub postać sterowaną przez gracza. 

Często rozważanym przykładem autonomicznych agentów są roboty funkcjonujące w 
środowisku Świata rzeczywistego. Są pewne istotne różnice między robotami a botami w grze 
komputerowej, wynikające z faktu, że boty działają w środowisku wirtualnym. 

Z przyczyn technicznych agenci działający w realnym Świecie posiadają fragmentaryczną 
informację o nim. Natomiast boty w grze komputerowej mogą mieć potencjalnie pełną 
informację o Świecie, w którym są osadzone, ponieważ są integralną częścią tego Środowiska. 
Dawałoby to botom nienaturalną przewagę i obniżałoby to wiarygodność symulacji Świata 
gry. Gracze posiadają fragmentaryczną wiedzę o środowisku gry, ponieważ poznają jego 
stan za pośrednictwem wizualizacji, tworzonej przez grę na postawie informacji zawartych w 
symulatorze środowiska gry. Boty, decydując o swoim zachowaniu, biorą pod uwagę jedynie 
te informacje, które byłyby dostępne dla danej postaci, gdyby była sterowana przez gracza. 
Ma to służyć lepszemu naśladowaniu człowieka, ponieważ gracz może na przykład próbować 
„oszukać” bota poprzez ukrywanie się poza jego polem widzenia. 

Inną istotną różnicą między środowiskiem rzeczywistym a wirtualnym są inne szanse 
powodzenia akcji wykonywanych przez postacie w tych środowiskach. Jeżeli w Świecie 
symulowanym akcja kończy się niepowodzeniem, to przyczyna tego niepowodzenia musi 
być zawarta w samym symulatorze. W grach komputerowych akcje najczęściej kończą się 
powodzeniem, żeby uprościć sterowanie postacią przez gracza bądź bota. Sterowane postacie 
w grze biegają bez problemu i nie przewracają się, co nierzadko zdarza się robotom kroczącym. 
Przemieszczanie się w Świecie gry komputerowej na ogół nie wymaga symulacji fizycznego 
modelu. 

Boty w grze komputerowej są sterowane za pomocą scentralizowanego algorytmu 
sterowania. Pojedynczy program komputerowy steruje zachowaniem wszystkich botów w 
grze komputerowej. Scentralizowane mechanizmy sterowania zachowaniem agentów są 


spotykane, gdy możliwa jest efektywna komunikacja między centrum sterowania a agentami. 
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Rysunek 1.1. Prosty schemat agenta 


W Srodowisku rzeczywistym nie zawsze mozliwa jest efektywna komunikacja, natomiast w 
środowisku wirtualnym — najczęściej jest. Jednak centralne sterowanie zachowaniem botów 
może doprowadzić do tego, że ich zachowania będą sprawiały wrażenie nieautonomicznych. 
Na przykład gracz może dostrzegać, że boty propagują między sobą informacje nienaturalnie 
szybko. Zatem konieczne jest, podobnie jak w przypadku percepcji wzrokowej, nałożenie 


ograniczeń na sposób i ilość wymienianych informacji między botami. 


1.2.3. Charakterystyka gry Counter-Strike 


Gry komputerowe często posiadają dwa tryby rozgrywki: jednoosobowy (tzw. singleplayer) 
i wieloosobowy (tzw. multiplayer). Popularność tego drugiego rośnie wraz rozwojem internetu. 
Scenariusz gry najczęściej występuje w trybie jednoosobowym. Natomiast gry wieloosobowe 
często przeprowadzane są w formie meczy. Gracze grają ze sobą przez pewien czas, zdobywając 
punkty, a pod koniec gry określana jest ogólna punktacja oraz wyłaniany zwycięzca. Tego typu 
gry tracą niejako immersyjny charakter rozgrywki na rzecz aspektów towarzyskich i rywalizacji 
między graczami [58]. 

Przykładem popularnych gier dostępnych wyłącznie w trybie multiplayer są wczesne 
wersje gry Counter-Strike. Autorzy tej gry postawili na realizm rozgrywki. Nie przyczynił 
się on w znaczący sposób do poprawienia immersyjności gry, bo nie było to w niej 
najważniejsze. Autorzy wprowadzili zasady, które uczyniły rozgrywkę odmienną niż w 
innych grach FPS dostępnych wtedy na rynku. W grze tej gracze są podzieleni na dwie 
drużyny: terrorystów i antyterrorystów. Mecze rozgrywa się na planszach w pięciominutowych 
rundach. Wyeliminowany gracz, w przeciwieństwie do innych gier, nie wraca do gry do 
końca rundy, co podnosi motywacje graczy aby dbać o bezpieczeństwo swojej postaci i 
bezpieczeństwo postaci graczy z drużyny. Cel dla każdej drużyny jest inny w zależności od 
planszy. Można wyróżnić 4 podstawowe typy plansz: „assasination” (AS), counter-strike” 
(CS), „defusion” (DE), „escape” (ES). W rozgrywce typu AS jeden z graczy w drużynie 
antyterrorystów przyjmuje rolę VIPa$, który musi dotrzeć do strefy bezpieczeństwa. Celem 
drużyny antyterrorystów jest eskortowanie VIPa do tego miejsca, natomiast terroryści próbują 
go wyeliminować. W rozgrywce typu CS antyterroryści odbijają zakładników, a celem 
terrorystów jest przeszkodzenie im w tym. W rozgrywkach typu DE zadaniem terrorystów jest 
podłożenie bomb w pewnej lokalizacji, a celem antyterrorystów jest niedopuszczenie do tego 
— mogą oni próbować nie dopuścić do podłożenia bomb lub rozbroić bombę, która została już 
podłożona. W rozgrywkach typu ES terroryści uciekają do stref bezpieczeństwa, a zadaniem 
antyterrorystów jest ich wyeliminowanie. Terroryści zwyciężają, jeżeli ucieknie więcej niż 
połowa z nich. Plansze typu ES zostały wycofane w fazie beta gry ze względu na problemy 


z zachowaniem równych szans dla obu drużyn przy zmiennej liczbie graczy, jednak sam typ 


6 VIP — ang. Very Important Person, bardzo ważna osoba 


18 





Rysunek 1.2. Widok FPP w grze Counter-Strike 


rozgrywki ES jest zaimplementowany w grze Counter-Strike i można spotkać plansze tego typu 
tworzone przez graczy. 

Społeczność graczy stworzyła też własne typy rozgrywki i właściwe im plansze. 
Przykładami takich trybów są „fight yard” (FY), „deathmatch (DM) oraz „aim” (AIM). W 
rozgrywkach na planszach FY dwie drużyny próbują się wzajemnie wyeliminować. Broń 
zazwyczaj leży na ziemi, a plansza jest niewielka. Ten typ rozgrywki jest bardziej dynamiczny 
niż klasyczna gra w Counter-Strike. Plansze DM i AIM charakteryzują się podobną, w stosunku 
do FY, rozgrywką. W grze typu AIM dostępna jest wyłącznie broń snajperska, a plansze są 
duże. Natomiast w trybie DM, gracze po wyeliminowaniu od razu wracają do gry, brak jest też 
z tego powodu podziału na rundy. 

Modyfikacja Counter-Strike została stworzona w 1999 roku przez dwóch hobbystów jako 
modyfikacja do gry Half-Life [41]. Wśród wielu innych modyfikacji, Counter-Strike szybko 
stała się tą najczęściej pobieraną. Producent gry Half-Life, firma Valve Software, wkrótce 
zdecydował się na dołączanie jej do dystrybucji gry Half-Life. Wkrótce gra stała się na 
tyle popularna, że była wydawana jako odrębny tytuł, pozostając jednak w dalszym ciągu 
modyfikacją gry Half-Life. W roku 2003 gra została przeniesiona na platformę Steam, dzięki 
czemu zyskała możliwość automatycznych aktualizacji i powstał też serwis społecznościowy 
skupiający fanów gry. W 2004 roku gra została przepisana od nowa w oparciu o nowy silnik” 
Source firmy Valve, dzięki czemu gra zyskała nowy, bardziej realistyczny i estetyczny wygląd. 
W okresie pisania tej pracy Counter-Strike w wersji 1.6 pozostaje w dalszym ciągu w czołówce 
10 najpopularniejszych gier multiplayer na platformie Steam, osiągając dzienną maksymalną 
liczbę graczy online na poziomie 40.0008. Gra Counter-Strike jest uważana również za sport 


elektroniczny [47] — rozgrywane są oficjalne turnieje i istnieją zawodowi gracze Counter-Strike. 


1 ang. engine, zwyczajowa nazwa oprogramowania odpowiedzialnego za interakcję modułów gry, m.in. 


grafikę, symulacje fizyki, obsługę wejścia/wyjścia, itp. 
8 źródło: statystyki udostępnione przez platformę Steam, zob. http://store.steampowered.com/stats/ 
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W pewnym stopniu usługą komplementarną do samej gry multiplayer jest kojarzenie ze 
sobą graczy w celu wspólnej gry online. W początkowych wersjach gry Counter-Strike rolę 
tej usługi pełniła sieć o nazwie WON”. Była ona stworzona na potrzeby gry Half-Life oraz jej 
modyfikacji. Po przejęciu roli sieci kojarzącej graczy przez wspomnianą wcześniej platformę 
Steam sieć WON została wyłączona, co pozostawiło wczesne wersje gry Counter-Strike bez 
usługi tego rodzaju. Odpowiedzią społeczności gry na to zdarzenie było stworzenie otwartego 
zamiennika sieci WON, o nazwie WON2, znanej też pod nazwa Steamless. 

Half-Life jest grą, którą można rozbudowywać i modyfikować, ponieważ do gry dołączony 
jest zestaw narzędzi jej twórców oraz dokumentacja jak z tych narzędzi korzystać — zestaw ten 
jest dystrybuowany pod nazwą Half-Life SDK. Counter-Strike w wersji 1.5 jest przykładem 
modyfikacji stworzonej z użyciem tych narzędzi. Co ciekawe, te same narzędzia można 
wykorzystywać, żeby rozbudowywać grę Counter-Strike, np. dodawać nowe plansze lub 
modyfikować wygląd postaci. Counter-Strike jest grą, wokół której jest skupiona społeczność 
nie tylko graczy, ale i też tzw. „modderów” [30] — osób, które tworzą modyfikacje do gry". 
Dzięki dużej ilości tworzonych przez nich narzędzi i zgromadzonej wiedzy możliwe było 
powstanie tej pracy — zastosowanie tych narzędzi i wiedzy było przydatne w celu wdrożenia 
architektury agentowej do algorytmu sterowania botami (rozdz. 4), jak również stworzenia 
środowiska do przeprowadzania testów (rozdz. 6). 

Bardzo przydatną modyfikacją w grze jest możliwość gry z postaciami sterowanymi przez 
komputer. Podstawowa wersja gry Counter-Strike nie udostępniała takiej możliwości, a do 
interesującej rozgrywki potrzeba było co najmniej czterech postaci w grze. Niekiedy było 
to problemem, więc potrzeba ta została szybko zaspokojona przez postacie sterowane przez 
komputer. W tym celu została stworzona modyfikacja do gry zawierająca boty. Sama gra 
Counter-Strike nie udostępnia otwartego API'! umożliwiającego stworzenie takiego modu 
łącznie z grą. Jednak posiada dobrze udokumentowane ABI'*, dzięki czemu stworzenie takiej 
modyfikacji jest możliwe. 

Boty tworzone przez modderów są dostępne w wersji gry 1.5. Wersja gry 1.6, która 
została wydana w 2003 roku, zawiera już boty dostarczone przez producenta — firmę Valve 
Corporation. Z uwagi na duże podobieństwo interfejsów binarnych obu wersji gry możliwe 
jest dalsze uruchamianie botów z wersji 1.5. W kolejnych wersjach: Counter-Strike: Condition 
Zero (2004) oraz Counter-Strike: Source (2004) wprowadzono zmiany polepszające wrażenia 


z gry w trybie wieloosobowym, dodano plansze w trybie dla jednego gracza oraz ulepszano 


? ang. World Opponent Network 

10 w przypadku gry Counter-Strike bardziej właściwym byłoby stwierdzenie, że są to modyfikacje do 
modyfikacji. 

I! ang. Application Programming Interface — ściśle określony zestaw reguł zdefiniowanych na poziomie kodu 
źródłowego, w jaki programy komunikują się między sobą. 

12 ang. Application Binary Interface — zestaw reguł decydujących o współpracy komponentów systemu, 
zdefiniowany na poziomie kodu wykonywalnego (tj. wersji binarnej). 
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działanie botów. Gra Counter-Strike: Source została zrealizowana z wykorzystaniem nowego 
silnika o nazwie Source. Poprawiło to znacznie atrakcyjność wizualną gry, ale z uwagi na 
inne interfejsy binarne, uruchamianie botów tworzonych przez graczy stało się niemożliwe. 
Spowodowało to zahamowanie działań modderów, mających na celu ulepszanie botów nie 
pochodzących od producenta gry, co objawia się zanikiem aktywności w repozytoriach kodów 
źródłowych! botów po roku 2004. Niemniej jednak oprogramowanie, stworzone przez 
modderów, stanowi ciekawy przedmiot badań, gdyż w przeciwieństwie do botów dostarczonych 
przez producenta, ich kod źródłowy jest dostępny publicznie i w celach naukowych można go 


legalnie modyfikować w dowolny sposób. 


1.3. Cel, teza i układ rozprawy 


Zaangażowanie graczy jest ważnym czynnikiem związanych ze dziedziną gier 
komputerowych. W przypadku gier komercyjnych zaangażowanie koreluje się dodatnio z 
zyskami ze sprzedaży gry. W przypadku gier niekomercyjnych wysokie zaangażowanie jest 
również pożądane, np. w przypadku gier mających na celu promowanie kampanii społecznych. 
Gra, w której gracze wykazują większe zaangażowanie, będzie charakteryzowała się większym 
zasięgiem. Oczywiście zyski są miarą, którą najłatwiej zmierzyć. Niekiedy istotne są też nie 
tylko ekonomiczne aspekty. 

Na potrzeby rozprawy rozdzielono reguły działania na planszy oraz zasad ogólnych. 
Takie rozwiązanie ułatwia programowanie botów, ponieważ zdejmuje z programisty botów 
konieczność każdorazowego tworzenia wzorców zachowań właściwych dla wielu plansz. 
Będzie wykazane, że zastosowanie tego podziału przynosi pozytywne rezultaty takie jak: 
poprawa wrażenia realizmu zachowań postaci w grze lub podniesienie komfortu gry, ponieważ 
programista może poświęcić więcej czasu na specjalizacje zachowania botów. 

W ramach rozprawy zaangażowanie jest mierzone jako ilość czasu przeznaczonego na 
rozgrywkę oraz poprzez opinie wyrażone w ankietach. Wrażenie realizmu zachowań botów, 
które jest subiektywne, również mierzono za pomocą ankiet i poprzez analizę wyników 
rozgrywek przeprowadzonych między botami, powstałymi jako wynik rozprawy, a innymi 
popularnymi botami. 

Narzędziem służącym do osiągnięcia specjalizacji zachowań botów zaprezentowanym w 
pracy, jest metodyka tworzenia botów z użyciem reguł decyzyjnych, zorganizowanych w 
grupy o różnych zakresach stosowalności. Na przykład wyodrębniona jest grupa reguł, która 
opisuje ogólne zasady gry oraz wyspecjalizowana grupa reguł stosowana tylko na konkretnej 
planszy. Specjalizacja jest przeprowadzania poprzez podanie przez programistę szczegółowych 
reguł, adekwatnych do sytuacji i miejsca. Przykładowo, w przypadku specjalizacji botów do 


'3 sa one dostępne pod adresem http://www.bots-united.com/ 
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konkretnej planszy, mogą to być reguły mówiące jak wykorzystać jej układ, żeby osiągnąć 
przewagę taktyczną. 

W ramach niniejszej rozprawy został stworzony, zgodnie z prezentowaną w rozprawie 
metodyką, algorytm sterowania botami noszący nazwę kBot. Boty kBot zostały umieszczone 
na publicznie dostępnych serwerach i przetestowane przez wielu graczy. Pomiary wydajności 
działania botów «Bot oraz wyniki badań ankietowych przeprowadzonych wśród graczy 
stanowią pozytywną praktyczną weryfikację wprowadzonej w rozprawie metodyki. 

Rozwiązania, polegające na sterowaniu zachowaniami postaci za pomocą języka 
skryptowego ogólnego przeznaczenia opartego na logice, nie były wcześniej publikowane. 
W rozwiązaniach znanych z literatury (patrz rozdz. 2) jeśli nawet opis zachowania postaci 
wykorzystuje reguły, to mają one uproszczoną formę, podobnie jak sposób użycia tych reguł. 
Metodyka prezentowana w niniejszej rozprawie pozwala na pełne wykorzystanie paradygmatu 
programowania w logice do definiowania zachowania postaci. 

Dalsza część rozprawy zorganizowana jest w następujący sposób. Rozdział 2 opisuje 
techniki sztucznej inteligencji stosowane w realizacji botów w grach FPS. Rozdział 3 
prezentuje sposób działania botów w grze Counter-Strike 1 przytacza przykłady działania 
wybranych botów, również tych znanych z innych gier FPS. Rozdział 4 opisuje formalny 
model architektury agentowej będącej przedmiotem tej rozprawy. Zostanie przedstawiony 
sposób projektowania zachowań botów i interakcji pomiędzy nimi z użyciem tejże architektury. 
Natomiast w rozdziale 5 zostanie zaprezentowany szkic wdrożenia tej architektury do botów 
w grze Counter-Strike. Rozdział 6 opisuje środowisko do przeprowadzania eksperymentów, 
miary użyte do badania jakości narzędzia oraz uzyskane wyniki. Rozprawę zamyka rozdział 7 
będący podsumowaniem najważniejszych wątków zawartych w rozprawie i wniosków z nich 


płynących. 


2. Techniki sztucznej inteligencji w planowaniu 


zachowań botów 


Zadaniem botów jest naśladowanie pewnych aspektów zachowania człowieka grającego 
w grę komputerową. Oczywistym faktem jest więc stosowanie w tym celu technik sztucznej 
inteligencji. 

Role botów w grze typu singleplayer i multiplayer mają odmienny charakter. W tej 
pierwszej boty są elementem Świata przedstawionego gry, a ich zachowanie jest adekwatne 
do scenariusza gry. Przykładowo, w grach typu „jeden przeciw wielu” zachowanie wrogich 
postaci powinno dawać graczowi szanse, pozwalające na pokonanie ich przeważającej liczby 
(patrz przykład 3.3.1). 

Boty w grze multiplayer naśladują zachowanie graczy uczestniczących w rozgrywce, a 
nie zachowanie postaci w Świecie przedstawionym. W grach o wysokim stopniu immersji 
gracze utożsamiają się z postaciami, którymi sterują. Dlatego, w takiej grze, nie ma różnicy 
między naśladowaniem zachowania graczy, a naśladowaniem zachowania postaci ze Świata 
przedstawionego. W grach o niskim stopniu immersji spotyka się zachowania postaci, które 
nie są właściwe dla ich roli, np. celowe wysadzanie się w powietrze, żeby postać efektownie 
podskoczyła. 

Zarówno w przypadku botów do gier typu singleplayer, jak i multiplayer, ważną kwestią 
jest określenie akcji możliwych do wykonania przez boty. W obu typach gier boty korzystają z 
podobnych akcji, jednak dokonując innych wyborów akcji uzyskuje się inne zachowanie bota. 


W przypadku gier FPS często spotkanym zabiegiem jest organizacja akcji w hierarchie. 


2.1. Hierarchia akcji i decyzji w Świecie gry 


Akcje możliwe do wykonania przez postacie w grach FPS są na ogół bardzo proste, 
ponieważ najczęściej polegają na przemieszczaniu się, wyborze broni oraz strzelaniu. Niekiedy 
są to jedyne akcje dostępne w środowisku gry, np. decyzja o zebraniu broni polega 
na przemieszczeniu się w miejsce, w którym ona się znajduje. Gry komputerowe typu 
FPS są grami czasu rzeczywistego — gracz uczestniczący w takiej rozgrywce może podjąć 


decyzję o wykonaniu akcji w dowolnym momencie. W rzeczywistości decyzje o wykonaniu 
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akcji podejmuje się w określonych momentach, ale niewielkie odstępy czasu między tymi 
momentami sprawiają, że gracz ma wrażenie podejmowania decyzji w dowolnej chwili. 

Środowisko gry ulega cały czas nieustannym zmianom na skutek akcji, podejmowanych 
przez każdą z osadzonych w nim postaci. Większość akcji ma natychmiastowy efekt, np. 
decyzja o ruchu naprzód powoduje przesunięcie bota o niewielki odcinek na planszy. Jednakże 
niektóre z akcji mogą mieć długofalowe i poważne konsekwencje dla rozgrywki, np. decyzja o 
oddaniu strzału do przeciwnika lub uruchomieniu bomby zegarowej. 

Z powodu potrzeby ciągłego wykonywania dużej ilości nieskomplikowanych akcji zachodzi 
potrzeba organizacji sekwencji tych akcji w pewne struktury, w celu uproszczenia algorytmu 
podejmowania decyzji dla botów. Naturalnym sposobem takiej organizacji jest wyróżnienie 
akcji wyższego poziomu, które posługują się akcjami prostymi do realizowania wyznaczonych 
im celów. Te dwa typy akcji, akcje proste i złożone, są definiowane na różnym poziomie 
abstrakcji (np. patrz tabela 2.1). Akcje złożone realizują skomplikowane cele, dzieląc je na 


cele podrzędne, realizowane przez akcje proste. 








Akcje proste Akcje złożone 
W którym kierunku się przemieścić? | Dokąd pójść? 
Czy zmienić broń? Jaką broń wybrać? 


Czy strzelić? 


Gdzie wycelować? Czy atakować innego gracza? 














Tablica 2.1. Przykładowe cele realizowane przez akcje proste i złożone. 


Wykonanie akcji złożonej przekłada się na wiele akcji prostych, więc wybór akcji złożonej 
przeprowadzany rzadziej niż wybór akcji prostej. 
Sposób organizacji akcji prostych w akcje złożone jest decyzją projektanta bota. Akcje 


złożone często posiadają zrozumiałą dla człowieka funkcję, którą łatwo da się opisać poprzez 





ich nazwę (np. Move — akcja ruchu, OpenDoor — akcja otwierania drzwi, SeekCover akcja 
szukania osłony, itp). Dzięki temu mogą być łatwiej używane przez programistów podczas 
tworzenia algorytmu decyzyjnego dla botów. Składanie akcji prostych w złożone jest naturalną 
decyzją z punktu widzenia inżynierii oprogramowania. Dla porównania, dowolny program 
komputerowy jest ciągiem instrukcji, lecz instrukcje te są zorganizowane w kodzie źródłowym 
w procedury i dalej w moduły. Podział taki ułatwia orientację w całej strukturze programu, co 
pozytywnie wpływa na rozwijanie i pielęgnację oprogramowania. Podobnych efektów można 
się spodziewać i w przypadku akcji złożonych. 

Akcje złożone niekoniecznie muszą być z góry ustalonymi sekwencjami akcji prostych. 
Mogą to być algorytmy decyzyjne, wybierające akcje proste w odpowiedzi na zaobserwowany 
stan środowiska gry, np. akcja przemieszczania się do wybranego punktu może brać pod 
uwagę wiedzę o rozmieszczeniu przeciwników na planszy. W robotyce taki sposób sterowania 


robotem nazywa się architekturą Brooksa [6] — polega ona na składaniu równoległym różnych 
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modułów sterowania i organizowaniu ich w warstwy o rosnącym stopniu abstrakcji. Tego typu 
architektura została użyta do implementacji akcji podejmowanych przez boty w grze Quake II 
[10]. Większość algorytmów podejmowania decyzji dla botów zaprezentowanych w rozdziale 
3 jest również wykonana w oparciu tę architekturę. 

Naturalnym pytaniem jest, czy można, poprzez analogię do składania akcji prostych w 
złożone, zorganizować same akcje złożone w struktury wyższego rzędu. Wtedy bot miałby do 
dyspozycji wiele algorytmów podejmowania decyzji złożonych i mógłby wybierać pomiędzy 
tymi algorytmami. Takie rozwiązania są również rozpatrywane, np. są to role bota, w 
zależności od których stosuje on różne algorytmy podejmowania decyzji złożonych. Pewien 
prosty przykład zastosowania ról został przedstawiony u bota MarineBot (patrz rozdz. 3.3.4). 
Role, jako struktury o wyższym poziomie abstrakcji niż akcje złożone, funkcjonują dłużej niż 
akcje złożone. Relacje między czasem funkcjonowania akcji prostej, złożonej oraz roli są 


przedstawione na rysunku 2.1. 


Rola 


Akcje złożone 


| 
I 
I 
| 
| 


Akcje proste 


ifzAoop Eryore1ory 





Czas 


Rysunek 2.1. Czas trwania roli, akcji złożonych i prostych. 


Role są wprowadzane jako element rozgrywki drużynowej (np. atak, obrona, wsparcie, 
zwiad), z ich pomocą można budować różne taktyki drużynowe. 
Na potrzeby tej pracy będzie czynione rozgraniczenie pomiędzy dwoma typami algorytmów 
decyzyjnych dla agenta, który stosuje podział na akcje złożone: 
— decyzje niskopoziomowe — podejmowane w ramach akcji złożonej, mające na celu wybór 
akcji prostej; 
— decyzje wysokopoziomowe — mające na celu wybór akcji złożonej, która będzie 


wykonywana przez bota. 


2.2. Metody koordynacji akcji złożonych 


W tym podrozdziale omówione zostaną sposoby koordynacji wykonywania akcji 
złożonych. Zakładamy, że akcje złożone są reprezentowane jako funkcje lub metody języka 
C++, które w wyniku swojego działania zwracają identyfikator akcji prostej. Rozpatrywana 


będzie funkcja action RunAi (Characteré&), która implementuje algorytm koordynacji 
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wykonania wielu akcji złożonych. Wartością zwracaną przez tę funkcję jest identyfikator 
akcji prostej, która ma być wykonana przez bota. Jako parametr funkcja przyjmuje strukturę 
Character, opisującą bota dla którego ma zostać podjęta decyzja. Funkcja RunAi jest 


wywoływana dla każdego bota w każdym epizodzie decyzyjnym środowiska gry. 


2.2.1. Drzewa decyzyjne 


Najprostszym sposobem koordynacji akcji złożonych jest wybór akcji złożonej za pomocą 
drzewa decyzyjnego podczas każdego wykonania funkcji RunAi. Przy takim sposobie 
koordynacji decyzje wysoko- i niskopoziomowe są podejmowane równie często. W takim 
przypadku, akcje złożone nie służą do wyróżnienia odrębnego algorytmu podejmowania decyzji 
wysokopoziomowych, który byłby uruchamiany rzadziej niż algorytm podejmowania decyzji 
niskopoziomowych. Służą one jedynie efektywnej organizacji kodu źródłowego. 

W przykładzie na listingu 2.1 jest przedstawiona przykładowa implementacja funkcji 
RunAi z użyciem drzewa decyzyjnego, zaimplementowanego za pomocą instrukcji 
warunkowych if-else. Na rysunku 2.2 przedstawiony jest schemat algorytmu 


przedstawionego na listingu 2.1. 


Listing 2.1. Kod przykładowego drzewa decyzyjnego. 


action RunAi(Characteré& c) 1 
if (c.good_health) { 
if (c.has_weapon) { 
return do_attack (c); 
} else if (c.weapon_near) { 





return do_get_weapon (c); 





} else { 
return do_look_for_weapon (c); 





} 
} else { 
return do_avoid_enemy (c) ; 


W przykładzie przedstawionym na listingu 2.1 szereg instrukcji warunkowych 
if-else realizuje funkcję drzewa decyzyjnego, czyli algorytm podejmujący decyzję 
wysokopoziomową. ' Natomiast decyzje niskopoziomowe są podejmowane w wyniku 
działania funkcji do_attack (Characteré c), do_get_weapon(Characteré c), 


do_look_for_weapon(Characteré c) i do _ avoid enemy (Characteré& c). 





Funkcje te pełnią rolę akcji złożonych i oznaczają odpowiednio atakowanie przeciwnika, 
zdobywanie broni, szukanie broni na planszy i ucieczkę przed przeciwnikiem. Informacje o 


środowisku gry są dostarczane botowi poprzez ustalanie wartości pól struktury Character. 
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Rysunek 2.2. Schemat drzewa decyzyjnego z listingu 2.1. 


Jeżeli bot ma mato punktów życia (pole good_health) to unika walki (akcja 
do_avoid_enemy). W przeciwnym przypadku bot sprawdza czy ma dobrą broń do walki 
(pole has_weapon) — jeżeli tak, to walczy z przeciwnikiem (akcja do_attack). W 
przypadku nieposiadania dobrej broni bot sprawdza czy broń znajduje się w pobliżu (pole 
weapon_near) — jeżeli tak, to bot bierze te broń (akcja do_get_weapon), a w przeciwnym 


przypadku szuka broni (akcja do_look_for_weapon). 





Wadą, wynikającą z konieczności każdorazowego podejmowania decyzji 
wysokopoziomowej przed decyzją niskopoziomową, jest możliwość występowania 
częstych zmian wykonywanych akcji złożonych. Model decyzyjny oparty na drzewie 
decyzyjnym nie posiada wbudowanych mechanizmów zapobiegających nadmiernie częstym 
zmianom decyzji o wyborze akcji złożonych, tzw. „inercji” akcji złożonych. Naturalnym 
sposobem na implementacje wyżej wymienionej „inercji? jest wyraźne oddzielenie 
algorytmu podejmującego decyzję wysokopoziomową i algorytmu podejmującego decyzję 
niskopoziomową, co może być realizowane za pomocą deterministycznych automatów 


skończonych. 


2.2.2. Deterministyczne automaty skończone 


Wydzielenie algorytmu podejmowania decyzji wysokopoziomowych, który byłby 
wykonywany rzadziej niż algorytm podejmowania decyzji niskopoziomowych, wymaga 
wyodrębnienia stanu, określającego akcję złożoną która ma być wykonywana między 


kolejnymi uruchomieniami algorytmu podejmowania decyzji wysokopoziomowych. Taki 
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wzorzec algorytmu, korzystający ze stanu, określa się mianem deterministycznego automatu 
skończonego, ze względu na podobieństwo do modelu obliczeniowego znanego w informatyce 
teoretycznej. 

W przypadku algorytmu sterującego zachowaniem botów, w którym wykorzystano taki 
wzorzec do koordynacji akcji prostych i złożonych, każdemu stanowi automatu odpowiada 
dokładnie jedna akcja złożona. Algorytm odpowiedzialny za realizację funkcji przejścia 
pomiędzy stanami podejmuje decyzje wysokopoziomowe, ponieważ powoduje zmianę akcji 
złożonej wykonywanej przez bota. 

Automat skończony da się formalnie opisać jako krotka (2, S, sg, 0, F), gdzie: 

— jest alfabetem wejściowym, 

— 0 jest zbiorem stanów, 

— So jest stanem początkowym, 

— 0 jest funkcją przejścia o sygnaturze ô : Sx — S, 

— F jest zbiorem stanów akceptujących (zachodzi F C 0). 


Działanie automatu może być opisane pseudokodem zaprezentowanym na rysunku 2.3. 


Data:w = (wi) o € NE x {1} — słowo wejściowe, przy czym k < oo 


& — S0; 

1=0; 

while w; # l do 
s 4+ ô(s, wz); 
1=1+1; 

end 


ifs € F then 
success (); 
else 
fail(); 
end 








Rysunek 2.3. Pseudokod automatu skończonego. 


Przez w oznaczany jest skończony ciąg symboli z alfabetu > zakończonym symbolem 
|. Wywołanie funkcji success oznacza akceptację słowa w przez automat, natomiast 
wywołanie funkcji fail oznacza odrzucenie słowa. 

W przedstawionej formalnej definicji automatu, słowa są skończone i składają się z symboli 
ze skończonego zbioru 2. W przypadku używania automatu skończonego jako mechanizmu 
podejmowania decyzji wysokopoziomowych, rolę słowa wejściowego pełni ciąg obserwacji 
stanu środowiska gry przez bota. Słowo, składające się z obserwacji, nie jest z góry znane, 
ponieważ bot, poprzez swoje zachowanie, wpływa na stan środowiska, a tym samym na przyszłe 


obserwacje. Innymi słowy, wartości kolejnych symboli w słowie mogą zależeć od stanu 
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automatu, który je czyta. Trudno również mówić o skończoności ciągu obserwacji, ponieważ 
botów raczej nie projektuje się z myślą o tym, że będą działały przez skończony czas. 

Do opisu położenia i czasu w realnym Świecie zwykle wykorzystuje się liczby rzeczywiste. 
Przy takim opisie Świata, zbiór jego możliwych obserwacji jest nieskończony. W środowisku 
gry FPS, będącym symulacją świata rzeczywistego, z przyczyn technicznych, np. z powodu 
ograniczonej pamięci komputera, zbiór obserwacji jest skończony (więcej o tej charakterystyce 
środowiska w rozdziale 4.2.1). W celu poprawy jakości symulacji konieczne jest zwiększenie 
zbioru obserwacji stanów Środowiska gry. W miarę rozwoju sprzętu komputerowego, nowe 
gry charakteryzują się większym zbiorem obserwacji niż gry starsze. Chociaż w konkretnej 
grze można założyć skończoność zbioru obserwacji, to nie należy zakładać, że zbiór ten jest w 
ogólności ograniczony. 

Z wyżej wymienionych względów, zwykle się nie wyróżnia stanów akceptujących 
w automacie do podejmowania decyzji wysokopoziomowych. Ważniejsze jest staranne 
skonstruowanie funkcji przejścia ô tak aby boty zachowywały się zgodnie z intencjami jego 
twórcy. Pożądane jest na przykład, aby bot nie znajdował się w stanie ucieczka, kiedy jego 
projektant chciałby, żeby bot w tych warunkach była w stanie atak. 

W przypadku utożsamienia akcji złożonych ze stanami automatu należy przyjąć, że stany 
mogą posiadać właściwe im parametry. Przykładem takiego parametru może być punkt 
docelowy dla akcji ruchu. W takim przypadku, przestrzeń stanów bota jest w istocie 
przestrzenią krotek, tj. 

S= wey x Pix: X Ph 


zbiór etykiet zbiory wartości parametrów 
stanow 


Jeżeli parametry stanu mają nieskończone dziedziny, np. są liczbami rzeczywistymi, to 
automat taki nie jest automatem skończonym. Jednak nawet w takim przypadku nazwa ta jest 
dalej wykorzystywana ze względu na analogie w funkcjonowaniu, tj. możliwość wyodrębnienia 
stanów i funkcji przejścia. 

Przykład zapisu algorytmu podejmowania decyzji złożonych w formie deterministycznego 


automatu skończonego przedstawiono na listingu 2.2. 


Listing 2.2. Fragment kodu, zapisanego w formie automatu skończonego, do podejmowania 
decyzji przez bota. 


enum ActionState { 
ATTACK, 
MOVE, 
RUN_AWAY, 
PER 


struct Character { 
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ActionState action_state; 

int move_to_location, ammo_location; 
bool attacked, low_health; 

2 


action select _low _ level action(Characterś character) { 





switch (character.action_state) { 
case ATTACK: 





return do _attack (character); // atakowanie 
case MOVE: 
return do move (character); // ruch 


case RUN_ AWAY: 
return do_run_away (character); // ucieczka 


z 


void select _high_level _action(Characters« character) { 
if (character.attacked 
&& character.low_health) { 
character.action_state = RUN_AWAY; 
} 


if (character. low_ammo 








&& character.ammo_location != NULL) { 
character.move_to_location = character.ammo_location; 
character.action_state = MOVE; 

} 
// 


action RunAi(Character& character) { 
if (character.need_new_action) { 
select_high_level_action(character) ; 





character.need_new_action = FALSE; 


} 


return select_low_level_action(character); 





Składowa action_state struktury Character określa akcję wykonywaną przez 


bota w danym momencie, czyli stan, w którym znajduje się automat właściwy dla 








danego bota. Funkcja select _high_level_action służy do podejmowania decyzji 





wysokopoziomowej, natomiast funkcja select _low_level_action — do decyzji 


niskopoziomowej. 
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Działanie funkcji select_high_level_action polega na zmianie wartości zmiennej 





action_state. Funkcja ta jest uruchamiana, w ramach wykonania funkcji RunAi, jedynie 
gdy składowa need_new_act ion ma wartość TRUE. Składowa ta może być modyfikowana 
przez akcje złożone tylko gdy konieczny jest wybór nowej akcji złożonej. Dzieje się 
tak na przykład, gdy zostanie osiągnięty cel akcji złożonej. Natomiast zadaniem funkcji 


select _low_level_action jest wybór akcji prostej będącej wynikiem funkcji RunAi. 





Procedury, których deklaracja znajduje się poza wyodrębnionym fragmentem kodu, to 
do_attack, do _move_to oraz do_run_away. Realizuja one akcje złożone poprzez 
wybór odpowiedniej akcji prostej dla danego bota. Stany automatu są symbolizowane poprzez 
typ wyliczeniowy z wartościami ATTACK, MOVE_TO oraz RUN_AWAY. Każdemu z tych 
stanów odpowiada właściwa mu akcja złożona. Stanowi ATTACK odpowiada akcja atakowania 
przeciwnika, zaś stanowi MOVE_TO — akcja ruchu do wybranego punktu. W rozważanym 
przykładzie akcja ta posiada parametr, move_to_location, który opisuje punkt docelowy 
tejże akcji. Natomiast stanowi RUN_AWAY odpowiada akcja ucieczki przed przeciwnikiem. 
Zmienna action_state zawiera aktualny stan automatu. Powiązanie akcji ze stanami jest 


realizowane za pomocą instrukcji warunkowej switch (linie 1-9). 





Procedura select _high_level_action wyraża funkcję przejścia między stanami 
automatu. W tym przykładzie jest ona realizowana poprzez instrukcje warunkowe if-else, 
które odwołują się do odczytów z sensorów bota. Odczyty te dostępne są jako pola struktury 
Character: attacked, ammo_location, low _ health, low _ammo. Oznaczają one 
obserwacje czy bot jest atakowany, gdzie widzi amunicję, czy posiada mało amunicji i czy 
posiada mało punktów życia. Oprócz samego przejścia między stanami, funkcja przejścia 


reguluje również parametry stanu, w przykładzie widoczne jest wykorzystanie omówionej 








wcześniej zmiennej move_to_location. Procedura select _low_level_action jest 
wykonywana zawsze, kiedy należy podjąć decyzję złożoną i nie powoduje ona podjęcia decyzji 
wysokopoziomowej. Jest to ulepszeniem w stosunku do wcześniej opisanego schematu drzew 
decyzyjnych. 

Niektóre boty są zaimplementowane w oparciu o automaty skończone [7]. Główną zaletą 
tego modelu jest jego prostota, co niestety jest też jego główną wadą, gdyż do stworzenia 
zaawansowanych zachowań potrzeba wielu stanów lub skomplikowanych funkcji przejścia 
między nimi. 

Technikę automatu skończonego stosuje się nie tylko w celu podziału na akcje proste i 
złożone. Może ona być stosowana do implementacji akcji złożonych, np. kupowania broni lub 
nawigacji, ponieważ w akcjach tych można wyróżnić pewną liczbę następujących po sobie faz 


działania. 
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2.2.3. Automaty niedeterministyczne 


Wadą algorytmów decyzyjnych opartych o automaty skończone jest determinizm procesu 
podejmowania decyzji. Zachowania deterministyczne są bardziej przewidywalne dla graczy 
niż zachowania niedeterministyczne. Dzięki temu raz znaleziona taktyka na pokonanie 
bota będzie pozwalała go łatwo pokonać w przyszłości. Jednym z możliwych rozwiązań 
tego problemu jest zastosowanie niedeterministycznych automatów skończonych, będących 
uogólnieniem automatów deterministycznych. W automacie niedeterministycznym wynikiem 
funkcji przejścia jest zbiór stanów, na które może zmienić się stan automatu wskutek wczytania 


symbolu wejściowego. Funkcja przejścia ma następującą sygnaturę: 
Sxi 


Szczególnym przypadkiem automatu niedeterministycznego jest automat probabilistyczny, 
w którym z wynikiem funkcji przejścia jest zmienna losowa scharakteryzowana rozkładem 
prawdopodobieństwa, zgodnie z którym następuje zmiana stanu [61]. Jest przy tym spełniony 
następujący warunek: 


dla każdego stanu s € S i symbolu wejściowego w € > zachodzi 


d(s,w) =90 
albo 

>, Post) =s]|=1 
s'€6(s,w) 


Zadanie programisty tworzacego algorytm sterowania botami za pomoca automatu 
probabilistycznego polega na określaniu wartości prawdopodobieństw wyboru akcji złożonych. 
Powstałe boty podczas gry dokonują wyboru akcji złożonej według tych prawdopodobieństw. 

Przykład automatu probabilistycznego znajduje się na listingu 2.3. Rożni 
się on od wersji deterministycznej z listingu 2.2 sposobem realizacji funkcji 


select _high_level_action. 





Algorytm sterujący botami, poprzez obserwacje świata gry wpływa na wartości dwóch 
zmiennych: attack_chance oraz run_away_chance. Pierwsza z nich oznacza szansę 
na podjęcie akcji ataku, a druga — szansę na podjęcie akcji ucieczki. Wybór akcji złożonej jest 
losowy, ale stosunek prawdopodobieństw wyboru akcji ataku i ucieczki jest proporcjonalny do 


wartości zmiennych opisujących szanse wyboru tych akcji. 


2.2.4. Automaty ze stosem 


Automat ze stosem jest rozszerzeniem definicji automatu deterministycznego poprzez 


uzupełnienie jej dodatkowo o strukturę danych — stos. Funkcja przejścia zależy nie tylko od 
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Listing 2.3. Fragment kodu, zapisanego w formie automatu probabilistycznego, do 
podejmowania decyzji przez bota. 


void select_high_level_action(Characteré& character) { 
double attack_chance = 0.01; 
double run_away_chance = 0.01; 








if (character.attacked) { 
attack_chance += 0.3; 
if (character.low_health) f 








attack _chance -= 0.1; 
run_away_chance += 0.4 
} 
if (character.low_ammo) { 
attack_chance -= 0.1; 
run_away_chance += 0.1 


double sum_chance = attack_chance + run_away_chance; 

if (rand() <= attack_chance / sum_chance) { 
character.action_state = ATTACK; 

} else { 


character.action_state = RUN_AWAY; 


symbolu wejściowego (czyli obserwacji), ale również od stanu stosu. Stan stosu jest zachowany 
między zmianami stanu automatu. Automat może modyfikować stan stosu poprzez dodawanie 
i usuwanie zeń obiektów. 

Algorytm do podejmowania decyzji przez bota określa się mianem automatu ze stosem, 
jeżeli można w jego opisie wyróżnić stan, funkcję przejścia oraz strukturę stosu, od której 
zależą wyniki funkcji przejścia. 

Zaletą użycia stosu w algorytmie podejmowania decyzji złożonych jest możliwość 
tworzenia planów w łatwy sposób. Bot może stworzyć plan i odłożyć na stosie kolejne 
cele, do których zamierza dążyć. Przykładem algorytmu sterującego botami wykorzystującego 
stos jest E[POD] (patrz rozdział 3.3.2). Obiektami, które odkłada ten algorytm na stosie, są 
akcje złożone. Dzięki temu boty E/POD] mogą tworzyć proste plany, poprzez odkładanie na 
stosie odpowiednich akcji, które kolejno będą wykonywać. Mogą one również reagować na 
nieprzewidziane okoliczności i wznawiać realizację planu, poprzez odkładanie na stosie akcji, 


mających na celu przeciwdziałanie tymże okolicznościom. 
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Przykład zapisu algorytmu podejmowania decyzji złożonych w formie automatu ze stosem 
przedstawiono na listingu 2.4. Przykład powstał jako rozbudowa przykładu z listingu 2.2 i 
korzysta z akcji złożonych tamże omówionych. W przykładzie na listingu 2.4 jako stosu użyto 
szablonu obiektu stack z biblioteki STL. 


Listing 2.4. Fragment kodu, zapisanego w formie automatu ze stosem. 


2 struct Character { 
3 std::stack<ActionState> action _ stack; 


4 // 


7 action select_low_level_action(Characteré& character) { 








8 switch (character.action_stack.top()) { 

9 case ATTACK: 

10 return do_attack (character); // atakowanie 
11 case RUN_AWAY: 

12 return do_run_away(character); // ucieczka 

13 id 


17 void select_high_level_action(Character& character) | 











18 if (character.attacked) { 

19 if (!character.low_health) { 

20 character.action_stack.push (ATTACK) ; 

21 r else { 

22 character.action_stack.push (RUN_AWAY) ; 
23 } 

24 } 

25 24 

26 } 


28 action RunAi(Character& character) { 











29 if (character.action_stack.empty()) { 

30 select_high_level_action(character) ; 

31 } 

32 return select_low_level_action(character)j; 











Przykład ten jest podobny do przykładu automatu deterministycznego zaprezentowanego 
w rozdziale 2.2. Najważniejszą różnicą jest definicja stanu bota jako stosu identyfikatorów 


akcji złożonych. W przeciwieństwie do algorytmów opartych na automatach skończoncych, 
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struktura reprezentująca bota nie ma wyróżnionej zmiennej need_new_action, która 
oznaczałaby konieczność podjęcia decyzji wysokopoziomowej. Rolę taką pełni sam stos. Jeżeli 
jest on pusty, oznacza to konieczność wybrania nowej akcji złożonej. 


Funkcja select_high_level_action odpowiada za podejmowanie decyzji 





wysokopoziomowych. Jej celem jest odłożenie na stos identyfikatora akcji złożonej. W 
zaprezentowanym przykładzie identyfikator jest wybierany poprzez drzewo decyzyjne 
zaimplementowane za pomocą instrukcji warunkowych if-else. Jednym z warunków 
sprawdzanych przez tę funkcję jest weryfikacja czy bot jest atakowany. W zależności od tego, 
czy bot ma dużo punktów życia, decyduje się on atakować lub uciekać. 

Algorytm podejmujący decyzje niskopoziomowe, reprezentowany jako funkcja 


select_low_level_action, polega na przekazaniu sterowania do tej akcji złożonej, 





której identyfikator znajduje się na wierzchołku stosu. Jeżeli wykonanie akcji złożonej 
jest zakończone, np. dlatego, że bot osiągnął cel danej akcji, to fakt ten powoduje usunięcie 
identyfikatora tej akcji z wierzchołka stosu. Podczas wykonywania akcji złożonej może pojawić 
się potrzeba dodania nowej akcji złożonej na stos, np. gdy bot wykonuje akcję przemieszczania 
się 1 widzi drzwi, które musi otworzyć, aby móc kontynuować przemieszczanie się. W takiej 
sytuacji odkłada na stos identyfikator akcji otwierania drzwi. Spowoduje to, że po otwarciu 


drzwi bot będzie kontynuować wybraną wcześniej akcję. 


2.2.5. Koordynacja równoczesnego wykonania wielu akcji 


Techniki zaprezentowane w rozdziałach 2.2.1 - 2.2.4 zakładają możliwość wykonania tylko 
jednaj akcji złożonej w danym momencie. Niekiedy boty potrafią wykonywać wiele akcji 
złożonych jednocześnie. 

Przykładowo, można wyróżnić akcje złożone związane z poruszaniem się i akcje złożone 
związane z celowaniem. Bot potrafi wykonywać w danym momencie jedną akcję związaną z 
celowaniem i jedną związaną z poruszaniem się. 

Ponieważ zakładamy możliwość wykonywania wielu akcji złożonych jednocześnie, 
konieczne jest określenie, jaka decyzja prosta jest podejmowana przez zbiór wykonywanych 
akcji złożonych. Tutaj będziemy zakładać, że wynik działania akcji złożonej dostarcza jedynie 
części informacji o decyzji niskopoziomowej, która ma zostać podjęta. Informacje te będą 
nazywane częściową decyzją niskopoziomową. Algorytm sterowania bota w trakcie działania, 
na podstawie podjętych decyzji częściowych, podejmuje ostateczną decyzję niskopoziomową 
będącą wynikiem działania funkcji RunAi. Zakładamy, że czynność łączenia decyzji 
częściowych jest realizowana przez funkcję Merge. 

Jeżeli możliwe jest wyróżnienie zbiorów akcji złożonych, spośród których częściowe 
decyzje podejmowane są niezależnie, to można dla każdego zbioru akcji złożonych zastosować 


jedną w omówionych wcześniej technik koordynacji wykonania akcji złożonych, a rezultaty 
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wielu akcji złożonych użyć do wyboru akcji prostej za pomocą funkcji Merge. Przykład takiej 


implementacji został umieszczony na listingu 2.5. 


Listing 2.5. Fragment kodu koordynującego równoczesne wykonanie wielu akcji złożonych. 


enum AimActionState { 


He 


enum MoveActionState { 


pa 


struct Character I 
bool need _aim action, need move _action; 
AimActionState aim _ action; 
MoveActionState move_action; 


action RunAi(Character& character) { 





if (character.need_aim_action) { 
select_high_level_aim_action (character); 


} 


if (character.need_move_action) { 





select _high_level move_action (character); 


return Merge( 
select _low_level aim action(character), 




















select _low _ level move _action(character)); 








Przykład ten wykorzystuje deterministyczny automat skończony do koordynacji akcji 
celowania i akcji poruszania się. Zmienne need_aim action i need _move_action 
oznaczają odpowiednio konieczność wyboru akcji złożonej dla celowania i poruszania się. 


Funkcje select _high_level_aim_actioniselect _high_level _move_action 





realizują wybór decyzji wysokopoziomowej. Ze względu na czytelność przykładu nie jest 





przedstawiona ich implementacja. Jest ono analogiczne do select _high_level_action 
z przykładu 2.2. Zadaniem tych funkcji jest wybór identyfikatorów akcji celowania 
(AimActionState) i akcji poruszania się (MoveActionState) oraz zapisanie ich w 


strukturze Character reprezentującej bota. 
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Wynikiem dziatania funkcji RunAi jest decyzja niskopoziomowa podjeta na podstawie 
wyników wykonania wybranych akcji złożonych dotyczących celowania i ruchu. Wynik 


akcji złożonej jest obliczany przez funkcje select_low_level_aim action dla 





akcji celowania i select _low_level _move_action dla akcji ruchu. Działanie 





tych funkcji nie jest zawarte w przykładzie, lecz jest ono analogiczne do funkcji 


select_low_level_action z przykładu 2.2. Funkcje te, na podstawie wartości 





składowej aim_action lub move_action, wybierają odpowiednią funkcję realizującą 


akcję złożoną. 


2.3. Metody planowania sekwencji akcji złożonych 


W tym podrozdziale przedstawione zostaną wybrane techniki planowania sekwencji 
akcji złożonych. W kontekście nomenklatury przyjętej w rozprawie, techniki te służą do 


implementacji ról sterujących zachowaniem bota. 


2.3.1. Algorytm STRIPS i system GOAP 


Boty, działając w grze komputerowej, realizują pewne właściwe im cele. W grze 
Counter-Strike cel drużyny zależy od typu planszy — może być to na przykład uwolnienie 
zakładników bądź wyeliminowanie drużyny przeciwnej. Udana realizacja zarówno decyzji 
niskopoziomowej, jak i wysokopoziomowej, skutkuje zmianą stanu środowiska gry, którą 
można się starać przewidzieć. Stanowi to punkt wyjścia do tworzenia algorytmów decyzyjnych 
dla botów, które planują całe sekwencje działań. W przypadku zastosowania takiego 
algorytmu do podejmowania decyzji wysokopoziomowych wybierany jest pewien cel (może 
być dyktowany np. przez rolę bota), a algorytm planowania tworzy sekwencję decyzji 
wysokopoziomowych, która prowadzi do tego celu. Decyzje te powodują wykonanie akcji 
złożonych przez bota, a w razie potrzeby wykonywane są działania korygujące. 

W kontekście inteligentnych agentów, algorytmem realizującym przeszukiwanie przestrzeni 
sekwencji decyzji, w celu znalezienia tych, które prowadzą do pewnego celu, jest algorytm 
STRIPS'. Środowisko działania agentów, dla którego możliwe jest planowanie z użyciem 
algorytmu STRIPS, ma taką własność, że jego stan daje się opisać za pomocą predykatów. 
Algorytm ten operuje na akcjach, z którymi są związane warunki wejściowe i rezultaty. 
Warunki wejściowe to predykaty odnoszące się do stanu środowiska. Aby bot mógł wykonać 
akcję, jej warunki wejściowe muszą być spełnione. Rezultat akcji specyfikuje zmiany, 
jakie zachodzą w środowisku po jej wykonaniu. Specyfikacja ta polega na opisie zmiany 
wartościowania predykatów opisujących stan środowiska. Parametrem algorytmu STRIPS 
jest cel, czyli zbiór predykatów, które muszą być spełnione po wykonaniu sekwencji akcji. 


' ang. Stanford Research Institute Problem Solver 
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Algorytm STRIPS pozwala znaleźć sekwencję akcji o tej własności, ze warunki wejściowe dla 
każdej akcji są spełnione w momencie, gdy jest ona wykonywana zgodnie z sekwencją. 

Danymi wejściowymi dla algorytmu STRIPS są: opis akcji możliwych do wykonania w 
środowisku, stan początkowy środowiska oraz stan docelowy. Dane te można opisać jako krotkę 
(P, A, Io, G): 

— FP jest zbiorem zmiennych zdaniowych, które opisują stany środowiska, 
— A jest zbiorem akcji możliwych do wykonania przez agenta, przy czym każda akcja to 
krotka (p+, py, er, €f), gdzie 

— p; € 2? to zbiór zmiennych zdaniowych, które powinny być prawdziwe, aby akcja 

mogła być wykonana, 

— pr € 2” to zbiór zmiennych zdaniowych, które powinny być fałszywe, aby akcja mogła 

być wykonana, 

— e € 2? to zbiór zmiennych zdaniowych, które będą prawdziwe po wykonaniu akcji, 

— e; € 2” to zbiór zmiennych zdaniowych, które będą fałszywe po wykonaniu akcji, 

— Ip € 27 jest początkowym stanem środowiska, 
— G € 2? jest docelowym stanem środowiska. 

Stan Środowiska jest opisany za pomocą zmiennych zdaniowych. Jest on tożsamy z pewnym 
podzbiorem zbioru P. Przynależność zmiennej zdaniowej do zbioru oznacza, że jest ona 
prawdziwa w stanie środowiska opisanym tym zbiorem. Brak takiej przynależności oznacza jej 
fałszywość. Cel jest pojedynczym stanem środowiska. Algorytm STRIPS znajduje sekwencję 
akcji, której wykonanie prowadzi do tego stanu środowiska. 

Niech apply będzie funkcją, która opisuje zmianę środowiska po wpływem akcji ze zbioru 
A, tj. 

apply: 2” x A +27 


Algorytm STRIPS wyszukuje sekwencji akcji a1,a2,...a, € A, która spełnia warunek 


prowadzenia do celu 


apply(...apply(apply (Jo, a1), a2) ...,a@n) =G 


Dla każdej akcji w tej sekwencji warunki wstępne, opisane zbiorami p; i pr, są spełnione po 


wykonaniu poprzedzających ją akcji, tj. 


I, = apply(...apply(apply (Jo, a1), a2) . - - , ak-1) 
ak = (Pri, Prj» €k,,€k,) E A 

Pri C Ik 

pr, N Ik = 0 
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Natomiast funkcja apply spełnia zależność 


o= (pe, Pf, Ct, Ef) EA 
VseaP et C apply(s, o) 
Veeor ej Mapply(s, 0) = Ø 


System planowania GOAP * wykorzystuje reprezentację powiązań między regułami 
wprowadzoną w STRIPS do planowania zachowania botów w grze FPS. Jest on używany do 
planowania zachowań przez boty w grach takich jak FE.A.R i No One Lives Forever autorstwa 
studia Monolith. Autorem systemu GOAP jest Jeff Orkin [42]. System GOAP wykorzystuje 
opis środowiska działania agenta za pomocą faktów w rachunku zdań oraz predykaty do opisu 
warunków wejściowych akcji i ich efektów. 

Orkin w swoich pracach traktuje akcje jako krawędzie w grafie skierowanym, którego 
wierzchołkami są stany środowiska gry. Jeżeli krawędź łączy dwa wierzchołki, oznacza 
to, że poprzez wykonanie zadania, które odpowiada krawędzi, możliwa jest zmiana ze 
stanu opisywanego przez wierzchołek wyjściowy do stanu odpowiadającemu wierzchołkowi 
docelowemu. Przy takiej reprezentacji zbioru akcji i stanów środowiska zadanie planowania 
działania dla botów jest zadaniem wyszukiwania ścieżki w grafie. Dodatkowo, Orkin wspomina 
również o hierarchii ogólności akcji i wybieraniu najpierw tych bardziej specyficznych, np. 
akcja AtakujZUkrycia jest bardziej specyficzna od Atakuj, bo ta pierwsza może być 
wykonana tylko w specyficznych warunkach. Autor proponuje rozwiązanie tego problemu za 
pomocą wprowadzenia „kosztów związanych z każdą akcją. W ten sposób zadanie planowania 
sprowadza się do wyszukiwania najtańszej ścieżki w grafie ważonym. 

Przykładowe przeszukiwanie grafu przez system GOAP jest zaprezentowane na rysunku 
2.4. Przykład opisuje zdobywanie drewna przez bota. Stan bota jest opisany za pomocą 
zmiennych zdaniowych. Zmienna has_axe oznacza posiadanie przez bota siekiery, a zmienna 
has_branches oznacza fakt posiadania przez bota drewna na opał. Bot tworzy plany, które 
prowadzą do prawdziwości zmiennej has_branches. Stan startowy jest oznaczony jako 
„Start”, a stany docelowe oznaczone są zielonym kolorem. 


Dostępne akcje to 





get_axe — podniesienie siekiery przez bota, 
— chop_wood — rąbanie drewna za pomocą siekiery, 
— get_branches — zebranie gałęzi leżących na ziemi. 


Akcje te tworzą krawędzie między wierzchołkami reprezentującymi stany bota. 


2 ang. Goal Oriented Action Planing 


39 



































chop_wood has_axe 
has_branches 
get_axe 
ea ee eae ae > has_axe 
3 SNE A athe = — has_axe 
get_branches has_branches 
Start 














Molzocótoet ted +has_branches 
ge__branches 











Rysunek 2.4. Przyktadowy graf przeszukiwany przez system GOAP. 


Jako korzyści wynikające ze stosowania planowania z użyciem systemu GOAP Orkin 
wymienia uzyskanie większej różnorodności zachowań bota niż w przypadku prostych drzew 
decyzyjnych przy porównywalnej ilości kodu specyfikującego działanie botów. W praktyce dla 


programisty oznacza to ułatwienie pracy potrzebnej do zdefiniowania zachowania bota. 


2.3.2. Planowanie predykcyjne 


Innym podejściem do planowania działań botów były badania przeprowadzane przez Pawła 
Wawrzyńskiego, Jarosława Arabasa oraz Pawła Cichosza [63]. Celem tego badania było 
sprawdzenie możliwości zastosowania sterowania predykcyjnego [9] do planowania zachowań 
botów. 

Do implementacji botów posłużono się akcjami złożonymi. Zdefiniowano je jako złożenie 
następujących elementów: 

— funkcji realizującej akcje, tj. wybierającej decyzję niskopoziomową w każdym cyklu gry, 

— warunku sukcesu (celu akcji), określającego stan środowiska gry, do którego ma zmierzać 
wykonanie akcji, 

— warunku wykonywalności, określającego kiedy może zostać zainicjowane wykonanie akcji, 

— kosztu i zysku, określających przewidywaną atrakcyjność akcji dla bota, 

— prognozy stanu końcowego, w przypadku udanego wykonania akcji. 

Bot posługuje się planami, będącymi sekwencjami zdefiniowanych wcześniej akcji. 
Utrzymuje on zbiór planów i realizuje te, które przynoszą najwyższy przewidywany zysk. W 
niektórych okolicznościach plany są odrzucane, np. w przypadku nieprzewidzianej planem 


zmiany stanu środowiska gry. Początkowo plany składają się z pojedynczej akcji. Są one 
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rozbudowywane o kolejne akcje w toku działania algorytmu. Zyski i koszty akcji związane są 

z punktami życia (HP*) bota w grze w następujący sposób: 

— pokonanie przeciwnika — zysk 100 HP, 

— zostanie pokonanym — strata 100 HP, 

— zebranie amunicji — liczba HP, jaką można zabrać przeciwnikowi zakładając, że każdy strzał 
jest celny, 

— zebranie apteczki — liczba HP, jaką można zyskać po zebraniu tego przedmiotu. 

W przypadku algorytmu planowania predykcyjnego nie jest wyszczególniony żaden 
stan docelowy, do którego dąży algorytm planowania. Bot, korzystający z planowania 
predykcyjnego, maksymalizuje przewidywany zysk w określonym horyzoncie czasowym. Zysk 
ten koreluje się z utrzymywaniem się bota długo w grze i eliminowaniem przez niego jak 


największej liczby przeciwników, co jest celem gier typu Deathmatch. 


2.3.3. Architektura SOAR i predykcja zachowań przeciwnika 


W grach FPS przeciwnicy podejmują akcje w środowisku gry i mogą one przeciwdziałać 
akcjom podejmowanym przez boty. Sposoby na zapobieganie takim działaniom przeciwników 
to: 

— liczenie się z faktem, że plan może się nie powieść — w przypadku braku możliwości 
realizacji wykonywanego planu, bot tworzy inny plan, 

— stosowanie drzewa gry — wybór akcji poprzedzony jest rozpatrywaniem potencjalnych 
decyzji przeciwnika i ich oceną. 

Stosowanie drzew gry jest typowe dla gier turowych. W takich grach algorytmy 
przeszukujące drzewa gry [2] często są w stanie określić strategię wygrywającą lub chociaż 
taką, która unika przegranej. Czynniki, które mogą wpłynąć na rozmiar drzewa gry to, m.in. 
średni stopień rozgałęzienia drzewa oraz głębokość drzewa. 

Średni stopień rozgałęzienia drzewa gry jest związany z liczbą możliwych decyzji do 
wykonania. Im większa liczba akcji do wyboru tym większy średni stopień rozgałęzienia. 
Na głębokość drzewa gry wypływa liczba uczestników rozgrywki oraz Średnia ilość akcji 
koniecznych do jej zakończenia. Im dłuższa rozgrywka, tym głębsze drzewo gry musi być 
przeszukane w celu znalezienia strategii wygrywającej. Głębokość drzewa gry rośnie również 
wraz z liczbą uczestników rozgrywki. 

W przypadku dużych drzew gry ich przeszukiwanie jest ograniczone do pewnej głębokości. 
W tym celu wykorzystuje się funkcję użyteczności służąca do oceniania „atrakcyjności stanu 
środowiska gry dla bota. Działanie algorytmu polega na wyborze akcji, która gwarantuje 
osiągnięcie w przyszłości stanu o maksymalnej funkcji użyteczności. To jak odległą przyszłość 


3 (ang. Hit Point, punkty życia), jednostka określająca ile postać w grze komputerowej jest w stanie 
wytrzymać uszkodzeń zanim zostanie wyeliminowana. 
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boty rozpatruja zalezy od rozmiaru drzewa i mocy obliczeniowej przeznaczonej na algorytm 
planowania zachowań botów. 

W grach FPS zbiór akcji prostych jest nieduży. Są to akcje związane głównie z ruchem i 
używaniem broni. Dlatego też potencjalne drzewo gry nie ma dużego rozgałęzienia. W grach 
FPS czas rzeczywisty jest symulowany poprzez częste epizody decyzyjne, a każda z podjętych 
decyzji ma niewielki wpływ na środowisko gry. Dopiero duża ich liczba powoduje znaczącą 
zmianę w środowisku gry. Z tych powodów drzewo gry ma głębokość tak dużą, że bot jest w 
stanie przeszukać jedynie bliską przyszłość. Dlatego bezpośrednie posługiwania się akcjami 
prostymi w drzewie gry jest niepraktyczne. 

Drzewo gry jest użyteczne w przypadku rozpatrywania akcji złożonych jako akcji 
wykonywanych przez boty. Drzewo gry ma wtedy mniejszą głębokość niż drzewo gry 
zbudowane w oparciu o akcji proste. Dzieje się tak ponieważ wykonanie akcji złożonej trwa 
znacznie dłużej i potrzeba ich mniej do zakończenia rozgrywki. Jednakże, rozgałęzienie drzewa 
zbudowanego w oparciu o akcje złożone jest większe, ponieważ boty mają do wyboru wiele 
akcji złożonych. Sposobem na złagodzenie tego problemu jest ograniczenie liczby możliwych 
do wyboru akcji, np. można przyjmować, że boty poruszają się wyłącznie do pewnego 
wyznaczonego zbioru punktów na planszy, a nie do dowolnego punktu. Taki zabieg stanowi 
dyskretyzację przestrzeni decyzyjnej, np. stany środowiska gry w których postać stoi w pobliżu 
punktu startowego, są ze sobą utożsamiane. Jest to również sposób, w jaki gracze myślą o 
rozgrywce: nie rozważają oni każdego szczegółu swojej obserwacji Świata gry, a jedynie pewne 
istotne dla niej elementy. 

Przykładem zastosowania drzewa gry, które operuje na akcjach złożonych, jest bot 
Quakebot [31]. Bot ten wykorzystuje drzewo gry w celu przewidywania zachowań graczy. 
Algorytm sterowania zachowaniem tych botów Quakebot jest zaprojektowany zgodnie z 
metodyką SOAR [32]. 

Nazwa SOAR jest akronimem od State, Operator and Result, czyli stan, operator i rezultat 
— jest to fundamentalny mechanizm tej metodyki. 

Ze względu na licznie inspiracje czerpane z psychologii poznawczej i kognitywistyki, 
wdrożone w postaci narzędzi programistycznych tej platformy, określa się ją mianem platformy 
kognitywistycznej. 

W ramach metodyki SOAR dostępnych jest również wiele narzędzi i bibliotek 
wspomagających programowanie agentów zgodnie z tą metodyką. Te narzędzia i biblioteki 
określa się mianem platformy SOAR. 

Schemat działania bota Quakebot przedstawia rysunek 2.5. 

W przypadku botów Quakebot stanem jest obserwacja Świata gry oraz zawartość pamięci 
roboczej bota. Natomiast operatorem jest akcja złożona możliwa do wykonania przez bota. 


Zastosowanie operatora polega na wyborze danej akcji złożonej do wykonania przez bota. 
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Rysunek 2.5. Cykl decyzyjny SOAR u bota Quakebot— współdziałanie stanów, operatorów i rezultatów. 


Postrzeganie polega na wczytaniu danych dostępnych dla bota ze środowiska gry. Jest 
ono realizowane poprzez interfejs pomiędzy algorytmem sterującym botem a środowiskiem 
gry. Opracowanie operatorów polega na wstępnym przetworzeniu danych, które są uzyskanych 
z procesu postrzegania. Celem procesu opracowania jest dostarczenie informacji, które 
będą wykorzystywane przy tworzeniu operatorów. Przykładem takiej informacji, może być 
informacja czy bot klasyfikuje liczbę swoich punktów życia jako niską czy wysoką. Podczas 
propozycji operatorów algorytm sterowania botem wykorzystuje reguły w celu wybrania 
operatorów adekwatnych do danej sytuacji. Operatory te są następnie oceniane, również za 
pomocą reguł. Gdy zbiór możliwych do wyboru operatorów jest ustalony, algorytm wybiera 
pewien operator ze zbioru i następnie stosuje go. 

W przypadku botów Quakebot operatory służą do podziału na akcje proste i złożone. 
Niektóre operatory nie mogą być zastosowane natychmiast i powodują wybór innych, 
prostszych operatorów w celu doprowadzenia środowiska gry do pewnego stanu docelowego. 
Z, tego powodu operatory uporządkowane są w hierarchię. Operatory znajdujące się wyżej w 
hierarchii mogą używać podlegających im operatorów. Zastosowanie operatora używającego 
operatorów pomocniczych rozciąga się przez wiele cykli decyzyjnych bota. Przykład 
wykonania akcji zbierania „powerupów” został przedstawiony na rysunku 2.6. 

Przedstawiony fragment działania bota dotyczy operatora „collect-powerups” polegającego 
na zbierania „powerupów” przez bota. W tym celu bot używa operatora „get-item”, który 
polega na zbieraniu przedmiotu. Do zastosowania go używa operatora o nazwie ,,goto-item”’, 
który polega na ruchu do przedmiotu. W tym celu używa sekwencyjnie dwóch operatorów 
„face-item”, który powoduje obrót w kierunku przedmiotu i „move-to-item”, który powoduje 
ruch w kierunku przedmiotu. Oba z tych operatorów używają operatorów czekania „wait”, 
ponieważ akcje sterowania położeniem bota nie są implementowane przez system SOAR tylko 


przez sterownik bota, któremu operatory zlecają wykonanie pewnych działań w Świecie gry. 
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Rysunek 2.6. Przykład wykonania operatora ,,collect-powerups” przez bota Quakebot 


Przewidywanie zachowań przeciwników następuje za pomocą częściowego przeszukania 
drzewa gry i jest mechanizmem tworzenia i wyboru operatora. 

Boty wykorzystują dostępne informacje o przeciwniku w celu przewidywania jego 
zachowania. Boty Quakebot korzystając z własnej obserwacji świata gry, próbuje zgadnąć stan 
wewnętrzny przeciwników i następnie przewidzieć jego postępowanie stosując własne reguły 
decyzyjne. Za pomocą tych reguł przeszukują część drzewa gry zbudowanego w oparciu o akcje 


złożone w celu zaproponowania odpowiedniego operatora. 


2.4. Skryptowe języki programowania botów 


Programowanie botów polega przede wszystkim na częstym wykonywaniu diagnozy 
sytuacji oraz wynikających z niej akcji. Z tego względu wykorzystanie języków programowania 
ogólnego przeznaczenia może być z punktu widzenia tworzenia kodu mniej efektywne niż 
wykorzystanie specjalizowanego języka. Poniżej zostaną przedstawione języki skryptowe, 


które są używane do programowania zachowania botów w grach komputerowych. 


2.4.1. ZBL/0 i AVDL 


ZBL/O [3] jest proceduralnym językiem programowania, stworzonym przez Eike 
Andersona, przeznaczonym do sterowania botami w grze komputerowej. Jego składnia jest 
podobna do języka PASCAL. Język udostępnia proste typy i struktury danych oraz możliwość 
definiowania procedur. 

Interpreter ZBL/O w każdym cyklu decyzyjnym gry wywołuje procedurę wejściową skryptu 
do sterowania botami. Każdorazowe uruchomienie tej procedury powoduje wykonanie akcji 
prostej, np. ruch w pewnym określonym kierunku. 

Motywacją do stworzenia tego języka była próba podziału pracy zespołu osób, które tworzą 
grę komputerową. W takim zespole programiści pracują nad silnikiem gry, czyli środowiskiem 


działania graczy i botów, natomiast projektanci plansz wykorzystują możliwości tworzenia 
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skryptów dla botów, w celu opisania ich działania na planszy, którą tworzą. Z punktu widzenia 
inżynierii oprogramowania jest to rozsądny podział, ponieważ zarówno plansza, jak i opis 
zachowania botów na planszy, stanowią dane wejściowe dla oprogramowania realizującego grę. 

Sam Eike Anderson jednak zauważa, że ZBL/O jest językiem programowania „niskiego 
poziomu”, z punktu widzenia analizy zachowania postaci w grach FPS, ponieważ operuje on na 
decyzjach niskopoziomowych. Jego praktyczne zastosowanie wymaga więc od projektantów 
dobrej umiejętności programowania, np. w celu implementacji podziału na akcje proste 
i złożone. W innym języku swojego autorstwa, AvDL*[4], Andreson decyduje się na 
wprowadzenie tego podziału na poziomie składni języka. Akcje złożone są implementowane za 
pomocą techniki automatu skończonego (patrz rozdział 2.2.2). Projektant, korzystając z języka 
AvDL, opisuje zachowanie bota poprzez specyfikowanie reguł, powodujących zmianę akcji 
złożonych wykonywanych przez danego bota. Natomiast same akcje proste są implementowane 


przez programistów silnika gry. 


2.4.2. Lua 


Lua jest językiem skryptowym, którego interpreter można uczynić częścią innych aplikacji. 
Interpreter można zintegrować z funkcjami takiej aplikacji, tak aby za pomocą skryptu Lua móc 
kontrolować pewien zakres działania aplikacji. 

Jest to najbardziej popularny język skryptowy dla gier komputerowych” — był użyty w takich 
produkcjach jak World of Warcraft czy Angry Birds. 

Lua jest językiem proceduralnym, posiada obsługiwane na poziomie składni zaawansowane 
struktury danych, takie jak tablice asocjacyjne. Dzięki temu definiowanie skomplikowanych 
struktur danych jest ułatwione i język Lua często jest wykorzystywany do tworzenia danych 
konfiguracyjnych. 

Interpreter Lua jest realizowany jako maszyna rejestrowa — skrypt przed wykonaniem jest 
kompilowany do kodu pośredniego obsługiwanego przez maszynę wirtualną Lua. Podnosi to 
wydajność działania interpretera, ponieważ skrypt nie jest przetwarzany jako tekst, ale ciąg 
instrukcji maszynowych. 

Wdrożenie języka Lua w konkretnej grze polega na zdefiniowaniu interfejsu pomiędzy 
interpreterem a silnikiem gry, tj. określenie, które funkcje silnika może wywoływać interpreter. 
W kontekście sterowania zachowaniem botów, mogą to być funkcje odpowiedzialne za 


podejmowanie decyzji wysokopoziomowych lub niskopoziomowych. 


4 ang. Avatar Description Language 
5 źródło: Wyniki ankiet Marka DeLoury, http://www.satori.org/2009/03/the-engine-survey-general-results 
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2.4.3. GiRL 


GiRL® jest językiem programowania przeznaczonym do tworzenia pętli sterowania dla 
autonomicznych robotów [22]. Koncepcja racjonalnego agenta jest wykorzystywana do opisu 
działania robotów. Może być ona również użyta do opisu działań botów w grze komputerowej. 
Dlatego niektóre z technik używanych do programowania robotów są wykorzystywane do 
programowania zachowania postaci w grach komputerowych [45]. Wykorzystanie języka GiRL 
jest przykładem takiej techniki. 

Wynikiem działania interpretera języka GiRL jest kod w języku C lub Scheme, który może 
być dołączony do kodu źródłowego realizującego działanie racjonalnego agenta. Pozwala to 
stosować optymalizację kodu wykonywalnego, co w efekcie prowadzi do dobrych wyników 
wydajnościowych. Możliwość kompilacji języka GiRL sprawia, że jest to rozwiązanie różne w 
sensie swojego przeznaczenia od języka ZBL/O0. W przypadku GiRL skrypt opisujący działanie 
bota nie jest daną wejściową dla oprogramowania, lecz jego tworzy jego część. Jest to więc 
narzędzie dla programistów, które zostało stworzone w celu uproszczenia opisu zachowań 
botów. 

Język GiRL został zastosowany w pracy Aarona Khoo do sterowania zachowaniem botów 
w grze komputerowej [27]. Khoo przedstawił tezę, iż skomplikowane systemy wnioskowania 
niekoniecznie przekładają się lepsze wrażenia u graczy. Wyjaśnia to faktem nieznajomości 
przez gracza stanu wewnętrznego bota, a jedynie tego, co wyraża poprzez swoje zachowanie. 
W przypadkach dwóch algorytmów podejmowania decyzji przez bota, gdy gracz nie jest w 
stanie dostrzec różnic w zachowaniu postaci sterowanych oboma algorytmami, Khoo sugeruje 
używanie tego mniej skomplikowanego. Zastosowanie prostszego algorytmu decyzyjnego 
przekłada się również na mniejsze zapotrzebowanie na moc obliczeniową potrzebną do 
sterowania botem. Jest to pożądana cecha, ponieważ bot otrzymuje bardzo mało czasu 
procesora na swoje działanie. Większość mocy obliczeniowej jest poświęcana np. na 
renderowanie grafiki, symulację fizyki świata gry, czy też obsługę protokołu sieciowego. 

Efektem działania skryptu w języku GiRL jest obliczenie wartości wektora zmiennych, 
które zostają przekazane silnikowi gry. Zmienne te opisują m.in. zmianę położenia bota, 
wybór broni lub decyzję od oddaniu strzału. Dzięki zastosowaniu języka GiRL możliwe 
jest opisywanie rozbudowanych warunków logicznych do sterowania botami. Przykład 
implementacji takiego takiego warunku opisujący podejmowanie decyzji o oddaniu strzału jest 
przedstawiony na listingu 2.6. 

Wyrażenie przedstawione w przykładzie ustawia wartość zmiennej logicznej shoot. 
Obliczanie wartości wyrażeń w języku GiRL jest zapisywane w notacji prefiksowej, natomiast 


przypisanie wykorzystuje notację infiksową. W przykładzie na listingu 2.6 symbol = jest 


6 ang. Generic Robot Language 
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1 
2 
3 
4 


Listing 2.6. Przyktad implementacji w jezyku GiRL warunku wyzwalajacego akcje strzelania 
(źródło: [27]). 
shoot = 
(and 
facing-enemy? 
not-fire-secondary? 





(or weapon-clip-not-empty? 
(= current-weapon crowbar)) 


(or 





(and enemy-long-range? 





current-weapon-long-range?) 
enemy-short-range? 
being-shot?)) 


wykorzystywany zarówno jako przypisane jak i porównanie, w zależności od wykorzystanej 
notacji. Wyrażenie zaprezentowane na listingu 2.6 jest koniunkcją (and) czterech warunków: 


— facing-enemy? — wyrażenie prawdziwe, gdy postać celuje w przeciwnika, 





not-fire-secondary? — wyrażenie prawdziwe, gdy postać nie strzela z broni 
dodatkowej, 
— (or weapon-clip-not-empty? (= current-weapon crowbar)) — 





alternatywa (or) dwóch warunków 





— weapon-clip-not-empty? — wyrażenie prawdziwe, gdy postać ma naboje w 
magazynku wybranej broni, 
— (= current-weapon crowbar) — sprawdzenie, czy wybraną bronią 


current-weapon jest łom crowbar, 








— (or (and enemy-long-range? current-weapon-long-range?) 





enemy-short-range? being-shot?)) — alternatywa trzech warunków 








— (and enemy-long-range? current-weapon-long-range?) = 








warunek prawdziwy, gdy przeciwnik jest daleko enemy-long-range? i postać ma 





broń dalekiego zasięgu current-weapon-long-range?, 
— enemy-short-range? wyrażenie prawdziwe, gdy przeciwnik jest blisko, 
— being-shot? wyrażenie prawdziwe, gdy postać jest atakowana przez przeciwnika. 
Chociaż GiRL jest językiem funkcyjnym przeznaczonym do operowania na sygnałach 1 
sensorach to jego sposób jego wykorzystania w pracy Khoo przypomina programowanie w 
logice. On sam mówi o regułach sterujących zachowaniem bota. Jako sposób pozyskiwania 


reguł decyzyjnych Khoo podaje wiedzę ekspercką innych graczy. 
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2.4.4. Cognitive Modelling Language 


Jezyk CML’[18] jest stosowany do automatycznego planowania zachowań postaci i 
pracy kamery w animacjach komputerowych. Jego autorem jest John David Funge. W 
animacjach komputerowych wymagania odnośnie wydajności są mniej restrykcyjne niż w grze 
komputerowej, ponieważ planowanie nie musi przebiegać w czasie rzeczywistym — proces 
renderowania animacji zazwyczaj trwa długo. Z tego powodu CML został zaprojektowany 
jako język interpretowany. 

W języku CML stany środowiska gry są opisane za pomocą predykatów. Akcje zawierają 
warunki wstępne i warunki końcowe. Warunki wstępne określają predykaty, które muszą 
być spełnione w stanie środowiska gry, aby akcja mogła być wykonana. Warunki końcowe 
specyfikują zmiany w wartościowaniu predykatów, które będą skutkiem wykonania akcji. 


Przykład specyfikacji akcji w języku CML przedstawiono na rysunku 2.7. 


action drop (Thing) possible when Holding (Thing); 
occurrence drop(Thing) results in !'Holding(Thing); 


Rysunek 2.7. Przykład deklaracji warunków wstępnych i końcowych akcji w języku CML. 


Przykład dotyczy akcji drop. Jest to akcja wyrzucenia przedmiotu trzymanego przez 
postać. Parametr Thing odpowiada przedmiotowi, który ma zostać wyrzucony. Warunkiem 
wstępnym tej akcji jest konieczność posiadania przedmiotu Thing przez postać. W 
przykładzie warunek wstępny jest wyspecyfikowany poprzez słowo kluczowe possible when. 
Dla akcji drop (Thing) zadeklarowany jest za pomocą słowa kluczowego results in warunek 
końcowy !Holding (Thing) — oznacza on brak przedmiotu Thing u postaci. 

Za pomocą języka CML programista specyfikuje reguły, które są wykorzystywane przez 
algorytm przeszukiwania przestrzeni sekwencji akcji w celu realizacji zadań dla botów. 
Programista może za pomocą języka CLog [17], będącego częścią języka CML, definiować 
opis konstrukcji sekwencji akcji, które są wykorzystywane podczas planowania działania 
postaci. Skrypty tworzone w języku CLog John David Funge określa mianem wiedzy 
dziedzinowej o działaniu postaci w symulacji oraz heurystyk, które usprawniają działanie 
algorytmu planowania. 

Przykładowy opis tworzenia sekwencji akcji o nazwie evade jest przedstawiony na rysunku 
2.8. Jest to akcja unikania drapieżnika przez ofiarę. 

Działanie zaprezentowanego pseudokodu jest następujące. Jeśli w pobliżu jest możliwa 
do znalezienia kryjówka niezajęta przez żadną ofiarę, to ofiara, dla której przeprowadzane jest 
planowanie za pomocą przedstawionego skryptu, próbuje się w niej schować. W przeciwnym 


przypadku próbuje znaleźć miejsce znajdujące się z dala od drapieżcy. 


1 ang. Cognitive Modelling Language 
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proc evade 
while Predator Approaching do 
sense ; 
update ; 
if Hr —Occupied(r) A Nearby(r) then 
(rh) (=Occupied(h) A Nearby(h)) ? ; hideBehind(h) 
else 
(rd) (AwayPredDir(d)) ? ; setGoal(d) 
done 
end 





Rysunek 2.8. Pseudokod deklaracji akcji złożonej w języku CLog (Źródło: [18]). 


Sekwencja evade jest rozbudowywana o nowe akcje dopóki spełniony jest warunek 
Predator Approaching. Sekwencja evade jest tworzona z akcji dla ofiary, natomiast warunek 
Predator Approaching odnosi się do drapieżnika. Jeśli programista nie prognozuje zmiany 
stanu drapieżnika w miarę planowania kolejnych akcji, to domyślnie jego stan nie ulega 
zmianie. 

Dwiema pierwszymi akcjami w sekwencji akcji evade są sense i update. Następna akcja 


jest wybierana za pomocą instrukcji warunkowej. Sprawdza ona, czy w stanie środowiska, 





po wykonaniu dwóch pierwszych akcji, zachodzi warunek 3r —Occupied(r) A Nearby(r), 
czyli czy istnieje taka wartość dla zmiennej r, dla której spełniona jest koniunkcja warunków 
—Occupied(r) i Nearby(r). Zmienna r identyfikuje pewną kryjówkę na planszy. Warunek 
—Occupied(r) jest spełniony, gdy kryjówka nie jest zajęta przez żadną ofiarę. Natomiast 
warunek Nearby(r) jest spełniony, gdy kryjówka znajduje się w pobliżu ofiary, dla której 
przeprowadzane jest planowanie. 

W przypadku spełniania opisanego warunku algorytm próbuje przypisać zmiennej h 
kryjówkę, która jest blisko i nie jest zajęta przez inną ofiarę. Szukanie wartości dla zmiennej 
h jest przeprowadzone poprzez iteracje w losowej kolejności (operator r) po zbiorze kryjówek 
do momentu, w którym wartość zmiennej h spełnia odpowiedni warunek. Następnie do planu 
dołączana jest akcja hideBehind(h), powodująca chowanie się za kryjówką identyfikowaną 
poprzez wartość zmiennej h. W przypadku nieistnienia wolnej kryjówki w pobliżu ofiary, 
wybierana jest, poprzez iterację w losowej kolejności, wartość dla zmiennej d. Zmienna ta 
określa kierunek, w którym będzie uciekać ofiara. Poszukiwana jest taka wartość zmiennej d, 
aby spełniony był warunek AwayPredDir(d). Warunek jest spełniony, gdy ofiara, wykonując 
ruch w kierunku opisanym zmienną d, oddala się od drapieżnika. Po przypisaniu wartości 
zmiennej d wykonywana jest akcja setG‘oal(d). Akcja to powoduje ruch w kierunku d. Oznacza 


to, że w przypadku niemożności znalezienia kryjówki, ofiara po prostu ucieka. 
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Zaletą pracy Funge'a jest silne podłoże teoretyczne. Autor omawia szeroko logikę, 
wykorzystywaną do wnioskowania o następstwach akcji w czasie. Logika ta bazuje na rachunku 


sytuacyjnym [46] oraz wykorzystuje elementy logiki epistemicznej. 


2.5. Podsumowanie 


W pracach teoretycznych poświęconych inteligentnym agentom widać silne tendencje 
do wykorzystania logiki i wnioskowania, w celu rozwiązywania problemów związanych z 
podejmowaniem decyzji i planowaniem działania. Tendencja ta przenosi się również na boty 
w grach FPS, gdzie zapis działania bota za pomocą reguł logicznych pojawia się zarówno przy 
podejmowaniu decyzji nisko-, jak i wysokopoziomowych. 

Widoczny jest częsty podział na akcje proste i złożone w celu uproszczenia modeli 
decyzyjnych. W wielu przypadkach autorzy botów wskazują na używanie wiedzy eksperckiej 
w celu konstrukcji modelu decyzyjnego. 

W kontekście przedmiotu tej rozprawy częste odwoływanie się w literaturze do technik 
opartych na logice, systemach regułowych oraz reprezentacji wiedzy, może stanowić istotną 
przesłankę do wypróbowania możliwości, jakie daje programowanie w logice w przypadku 
programowania zachowań botów. W przykładach przedstawionych w tym rozdziale, techniki 
wykorzystujące logikę były jedynie częścią innego modelu, np. planowania czy też adaptacji. 

W następnym rozdziale zostaną przedstawione praktyczne implementacje algorytmów 


sterujących botami, z których wiele wykorzystuje przedstawione w tym rozdziale techniki. 


3. Omówienie działania wybranych botów w grach 
rodziny Half-Life 


W rozdziale tym zostanie przedstawiony sposób działania symulatora środowiska gry 
Half-Life oraz architektura wybranych botów działających w grze Half-Life i jej modyfikacjach. 
Informacje na temat historii powstawania gry Counter-Strike zostały zawarte w rozdziale 1.2.3, 


natomiast w tym rozdziale zostaną przedstawione informacje dotyczące kwestii technicznych. 


3.1. Funkcjonowanie środowiska gry i jego modyfikacji 


Gra Half-Life jest podstawowym elementem systemu, który jest potrzebny do 
funkcjonowania gry Counter-Strike. Silnik gry Half-Life, nazywany przez autorów GoldSrc, 
został wykonany jako daleko idąca rozbudowa silnika gry Quake I'. Gra Half-Life może być 
rozbudowywana przez użytkowników przez tworzenie tzw. modyfikacji. Gra Counter-Strike 
jest modyfikacją gry Half-Life. 

Tworzenie modyfikacji do gry jest możliwe dzięki udostępnieniu przez producenta 
dedykowanych do tego celu zestawu narzędzi, znanego pod nazwą Half-Life SDK. Zestaw 
ten, oprócz samych narzędzi dla projektantów i programistów, zawiera bogatą dokumentację, 
kody źródłowe modyfikacji wykonanych przez producenta oraz szablony do generowania 
poszczególnych elementów modyfikacji, np. nowych rodzajów uzbrojenia czy też typów 
przeciwników. Gotowy pakiet z modyfikacją zawiera nowe pliki multimedialne (tj. modele 3D, 
dźwięki, mapy, itd.) oraz skompilowany kod, realizujący nową lub zmienioną funkcjonalność 
gry. Jest on dołączany do silnika Half-Life jako biblioteka ładowana dynamicznie (np. DLL w 
systemie Windows). Silnik gry Half-Life jest w stanie uruchomić jedną modyfikację w danym 
momencie. Udostępnia on zestaw funkcji, z których modyfikacja może korzystać podczas 
swojego działania. Znajdują się tam funkcje, wiążące wprowadzane przez modyfikację obiekty 
ze światem gry, oraz wyzwalacze, pozwalające na reagowanie na zdarzenia zachodzące w tym 
Świecie. 

Gra Counter-Strike, podobnie jak gra Half-Life, była rozbudowywana przez społeczność 
modderów. Jednak doszło do tego w inny sposób niż w przypadku gry Half-Life. Mianowicie, 
autorzy gry Half-Life przewidzieli możliwość tworzenia modyfikacji i dali graczom narzędzia 

1 


silnik ten jest popularny w inżynierii gier komputerowych z uwagi częste jego zastosowanie i 
rozbudowywanie przez różnych twórców gier. 
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do tego służące oraz dokumentację. W przypadku gry Counter-Strike gracze, poprzez 
zastosowanie inżynierii wstecznej”, wytworzyli sami takie narzędzia i bazę wiedzy. W grze 
Half-Life istnieje mechanizm pozwalający na ładowanie i wykonanie kodu modyfikacji. Do 
modyfikowania gry Counter-Strike gracze wykorzystali znajomość API między Counter-Strike 
a Half-Life, mianowicie między grą i jej modyfikacją wyprowadzono dodatkową warstwę 
sterowania, która przechwytuje każde wywołanie funkcji pomiędzy nimi. Początkowo każda 
modyfikacja gry Counter-Strike zawierała własną wersję takiej warstwy i możliwe było 
uruchomienie gry Counter-Strike z jedną modyfikacją w danym momencie. Jednak ze względu 
na ustalone API, kod ten był powtarzalny i możliwa była implementacja takiej warstwy jako 
osobnego komponentu, który może ładować wiele modyfikacji gry Counter-Strike jednocześnie 
i propagować między nimi przechwytywane wywołania API silnika gry Half-Life. Komponent 
realizujący funkcję takiej warstwy pośredniej jest znany pod nazwą MetaMod, a modyfikacje 
gry Counter-Strike obsługiwane przez niego określa się mianem wtyczek MetaModa. Schemat 


funkcjonowania MetaModa został przedstawiony na rysunku 3.1. 
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Rysunek 3.1. Działanie wtyczek MetaModa 


Strzałki na diagramie oznaczają kolejność, w jakiej wywoływane są poszczególne elementy 
systemu. Najpierw gra Counter-Strike przekazuje informacje o zdarzeniach ze świata gry do 
MetaModa (1). Następnie MetaMod propaguje te informacje do poszczególnych wtyczek (2 - 
7). Wtyczki te mogą modyfikować zachodzące zdarzenia, np. sterować działaniem postaci, 
które są sterowane przez gracza. Na końcu zdarzenia, będące wynikiem działania wielu 
wtyczek są, przekazywane do środowiska gry Half-Life w celu zmiany stanu środowiska gry (8). 
Na podstawie stanu środowiska gry Half-Life tworzona jest wizualizacja dostępna dla graczy. 

Zaletą MetaModa jest możliwość dynamicznej aktywacji i dezaktywacji oraz 
monitorowania działania poszczególnych wtyczek. Obecnie duża część dostępnych modyfikacji 


gry Counter-Strike może być uruchamiana jako wtyczki MetaModa. 


2 ang. reverse engineering, proces badania oprogramowania, w celu ustalenia, jak ono dokładnie działa. 


Często przeprowadzane, aby wprowadzić do niego modyfikacje. 
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Modyfikacje gry Counter-Strike, bez względu na to, czy są uruchamiane jako wtyczki 
MetaModa, czy nie, są kompilowane jako biblioteki współdzielone, pisane najczęściej w języku 
C++. Rozwiązanie takie jest niewygodne do tworzenia prostych wtyczek, które często są 
stosowane przez administratorów na serwerach z grą Counter-Strike. Tworzenie takich wtyczek 
jest ułatwione dzięki wtyczce MetaModa o nazwie AMX Admin Mod. Dostarcza ona języka 
skryptowego zintegrowanego z działającym na serwerze środowiskiem gry Counter-Strike. 
AMX jest zatem jeszcze jedną pośrednią warstwą sterowania pozwalającą na wprowadzanie 
dodatkowych funkcji w środowisku gry. Schemat jego działania został przedstawiony na 


schemacie 3.1. 


1. 










Rysunek 3.2. Działanie wtyczki AMX Admin Mod i jej skryptów 


Podobnie jak na diagramie 3.1 numeracja strzałek określa kolejność przekazywania 
informacji o zdarzeniach zachodzących w środowisku gry Counter-Strike. Najpierw gra 
Counter-Strike przekazuje informacje o zdarzeniach ze świata gry do Met aModa (1), ten zaś 
do wtyczek, które kontroluje (2 - 4 oraz 9 - 11). Jedną z tych wtyczek jest AMX, więc AMX 
otrzymuje informacje o zdarzeniach ze świata gry za pośrednictwem MetaModa (4). Następnie 
informacje o zdarzeniach ze Świata gry są przetwarzane za pomocą skryptów AMX (5 - 8). 
Gdy AMX zakończy przetwarzanie zdarzenia za pomocą wszystkich skryptów, to sumaryczny 
wynik tego działania jest przekazywany kolejnym wtyczkom kontrolowanym przez MetaMod 
(10) i ostatecznie informacje trafiają (12) do silnika gry Half-Life, aby zmienić stan środowiska 
gry. 

AMX jest modyfikacją, która pozwala na łatwe zmienianie zasad działania serwera gry. 
Przykładami jej zastosowania jest tworzenie wtyczek do zbierania statystyk z rozegranych 
meczy lub wprowadzanie dodatkowych komend dostępnych dla administratora. 

Główną zaletą AMX jest wprowadzenie języka skryptowego, pozwalającego na pozbycie się 
narzutu pracy, związanego z tworzeniem osobnej wtyczki dla prostych modyfikacji. Niniejsza 
rozprawa jest w pewnym stopniu ideowo bliska AMX, gdyż wprowadza język skryptowy do 
sterowania zachowaniem botów na wysokim poziomie abstrakcji, bez konieczności zgłębiania 


dokładnych szczegółów implementacyjnych bota i zasad działania środowiska gry. Ma 
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to za zadanie umożliwić łatwe modyfikowanie nie tylko samych zasad gry, ale też reguł 
interakcji pomiędzy botami, co może być przydatne do tworzenia nowych trybów rozgrywki. 
Wtyczka AMX została wykorzystana do stworzenia narzędzi diagnostycznych do prowadzenia 
eksperymentów (rozdz. 6). 

Jeszcze jedną modyfikacją, o której warto wspomnieć, jest OGC. O ile AMX jest 
modyfikacją, która działa w trybie serwera gry, to OGC działa w trybie klienta. Ideą 
działania tej modyfikacji jest zmiana sposobu wizualizacji informacji o stanie środowiska 
gry, otrzymywanych z serwera gry. Przykładowo, OGC może wyświetlać położenia graczy 
z przeciwnej drużyny na miniaturce mapy lub powalać graczowi widzieć przez ściany. W 
środowisku graczy używanie OGC jest uznawane z niezgodne z zasadami ,,fair-play” i gracze 
podłączający się do serwera za pośrednictwem klienta z modyfikacją OGC są usuwani z tego 
serwera. Z tego względu OGC nie jest bardzo aktywnie rozwijaną modyfikacją. Jednak dzięki 


niej powstał szablon projektu do tworzenia modyfikacji klienckich. 


3.2. Funkcjonowanie botów w Środowisku gry 


W tej części pracy zostanie omówiony sposób działania botów w środowisku gry. Niewiele 
jest publikacji dokumentujących sposób implementacji botów dla Counter-Strike, dlatego 
znaczna część informacji została pozyskana przez autora rozprawy poprzez analizowanie 


kodów źródłowych botów tworzonych przez społeczność skupioną wokół gry Counter-Strike. 


3.2.1. Komunikacja ze silnikiem gry 


Counter-Strike jest grą sieciową funkcjonującą w architekturze klient-serwer. Każdy klient 
gry Counter-Strike posiada symulator środowiska gry, którego stan jest synchronizowany z 
innymi klientami za pośrednictwem serwera. W każdym środowisku gry można wyróżnić 
dwa typy postaci: lokalne i zdalne. Informacje na temat postaci lokalnych są rozsyłane ze 
środowiska klienckiego za pośrednictwem serwera do innych środowisk. Natomiast informacje 
o postaciach zdalnych w innych środowiskach klienckich są odbierane z serwera. Każda postać 
może być lokalna w jednym środowisku klienckim, dla pozostałych środowisk będzie to postać 
zdalna. 

W środowisku gry Counter-Strike funkcjonują postacie, które można podzielić na 4 
kategorie: 

1. postać lokalna sterowana przez gracza, 
2. postać zdalna sterowana przez gracza, 
3. bot lokalny, 
4. bot zdalny. 
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Bot lub gracz, sterujący każdą spośród tych czterech kategorii postaci, posiada odmienny 
sposób interakcji ze środowiskiem gry komputerowej. Schematyczny sposób interakcji został 


przedstawiony na rysunku 3.3. 


Gracz Gracz Bot Bot Bot 
lokalny zdalny zdalny lokalny lokalny 
Zdalne środowisko gry | 
A 


BI ' 


Środowisko 


| TCP/IP | Krze 
gry 


Mod ; 


Modyfikacja Counter-Strike 


Silnik gry Half-Life 


Rysunek 3.3. Interakcje między uczestnikami rozgrywki a komponentami środowiska gry. 


Gracze zdalni i lokalni sterują swoimi postaciami w środowisku gry, korzystając z urządzeń 
wejścia takich jak mysz i klawiatura. Gracze poznają środowisko gry za pośrednictwem 
urządzeń wyjścia: monitora i głośników. Każdy gracz, zdalny lub lokalny, steruje dokładnie 
jedną postacią w grze. 

Algorytm sterujący botem zdalnym, jak i botem lokalnym, działa jako składniki środowiska 
gry i podejmuje decyzje w każdym cyklu gry. Steruje botami poprzez generowanie informacji 
o zdarzeniach dotyczących postaci i przekazywanie tych informacji do silnika gry Half-Lifelub 
MetaModa. Bot, zdalny lub lokalny, współdzieli pamięć z innymi botami, działającymi w 
grze. Bot zdobywa dane o środowisku gry, odczytując dane bezpośrednio z symulatora, bez 
odwoływania się do silnika graficznego. Z, tego powodu symuluje te aspekty wizualizacji, które 
wypływają na zachowanie graczy, np. pole widzenia. 

Gracze zdalni i boty zdalne działają w zdalnym środowisku gry. W rozgrywce 
wieloosobowej stan środowiska gry jest uzgadniany za pośrednictwem serwera i rozsyłany do 
wszystkich klientów. Na skutek opóźnień w komunikacji sieciowej, między środowiskami 
poszczególnych klientów mogą wystąpić rozbieżności, tj. stany tych środowisk mogą się 
różnić. Gracze zdalni mogą zatem podejmować inne decyzje niż podejmowaliby w lokalnym 
środowisku. Stopień rozbieżności pomiędzy środowiskami lokalnym i zdalnym zależy od 


jakości komunikacji sieciowej między nimi. W skrajnych przypadkach niemożliwe jest 
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prowadzenie skoordynowanej rozgrywki ze względu opóźnienia w synchronizacji stanów 
środowiska gry pomiędzy klientami. W takim przypadku rozgrywka jest najczęściej 
przerywana. Z tego powodu gracze często wybierają, spośród dostępnych serwerów, te z 


lepszymi parametrami komunikacji sieciowej [67]. 


3.2.2. Parametry botów 


Algorytm sterujący botami otrzymuje od środowiska gry dokładne dane, dlatego jest w 
stanie precyzyjnie sterować zachowaniem botów i może mieć dużą przewagę nad człowiekiem 
grającym w tę samą grę. Jednak gracze odznaczają się różnym stopniem sprawności, dlatego 
ważną kwestią jest możliwość dostosowywania poziomu trudności rozgrywki prowadzonej 
przez boty do umiejętności gracza. Można to osiągnąć poprzez naśladowanie ludzkich 
ograniczeń w interakcji ze środowiskiem gry. Często stosowanym sposobem stopniowania 
poziomu trudności rozgrywki prowadzonej przez boty jest podawanie wartości parametrów 
liczbowych, wpływających na różne aspekty ich działania. Można wyróżnić parametry 
dotyczące sposobu przetwarzania informacji o stanie środowiska gry oraz parametry dotyczące 
zachowania bota. W pierwszej kategorii można spotkać parametry o nazwach odnoszących się 
do procesów poznawczych, np. „percepcja”, inteligencja” czy „pamięć”. Z kolei, przykładami 
parametrów dotyczących zachowania bota są „celność” lub „sprawność poruszania się”. 

Percepcja może być rozumiana jako zdolność do odbierania bodźców pochodzących ze 
środowiska i interpretowania ich. Boty odbierają inaczej informacje o Świecie gry niż człowiek 
— różnice te były wspomniane wcześniej. W niektórych implementacjach botów percepcja 
charakteryzowana jest za pomocą parametru liczbowego dla każdej bota z osobna. Parametr 
ten określa „spostrzegawczość” bota, np. ma on wpływ na zasięg, w jakim bot słyszy 
przeciwników, lub kąt widzenia, w jakim dostrzega przeciwników. Boty o wyższej wartości 
tego parametru są w stanie łatwiej dostrzec swoich przeciwników i wcześniej zareagować na 
nich. 

Pamięć może być rozumiana jako zdolność do rejestrowania i ponownego przywoływania 
wrażeń zmysłowych lub myśli. Parametr charakteryzujący pamięć bota ma wpływ na 
ilość czasu przez jaką są przechowywane w pamięci informacje o minionych zdarzeniach 
zachodzących w Świecie gry. Przykładowo, jeżeli bot ścigając przeciwnika korzysta z 
informacji o ostatnich znanych jego położeniach, to parametr pamięci w tym przypadku 
może kontrolować czas, przez jaki informacje tych położeniach są przechowywane. Warto 
wspomnieć, że niekiedy wpływ na wartość tego parametru ma ilość pamięci operacyjnej 
dostępnej dla bota. 

Boty często są charakteryzowane parametrem liczbowym o nazwie „inteligencja. Określa 
on najczęściej całościową jakość algorytmu funkcjonowania bota. Może wpływać pośrednio 


na parametry percepcji i pamięci, tj. parametr inteligencji botów jest określany przez gracza 
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i na jego podstawie nadawane są wartości innych parametrów dla poszczególnych botów. 
Często ten parametr jest ściśle powiązany z samym sposobem podejmowania decyzji przez 
bota. Przykładowo, w przypadku stosowania drzew decyzyjnych, bot może nie wchodzić w 
pewne gałęzie drzewa zawierające wyspecjalizowane zachowania i poprzestawać na stosowaniu 
pewnych ogólnych taktyk działania. Zmniejszanie wartości tego parametru prowadzi na ogół 
do podejmowania gorszych decyzji niż w przypadku wyższej wartości tego parametru — z tego 
powodu rozgrywka staje się wtedy prostsza dla gracza. 

Gracz, aby wycelować, posługuje się celownikiem, widocznym na ekranie gry. Do 
wycelowania w wybrany przez siebie punkt potrzebuje trochę czasu. Dodatkowo często 
się myli, celując faktycznie w inny punkt niż zamierzał. Boty natomiast mają możliwość 
natychmiastowego i precyzyjnego wycelowania w dowolny punkt w świecie gry. Celowanie 
polega na sprecyzowaniu przez nich wektora, wzdłuż którego zamierzają oddać strzał. Taki 
sposób interakcji ze środowiskiem gry może dawać botom przewagę nad człowiekiem, dlatego 
też twórcy botów symulują ludzkie ograniczenia u botów poprzez dodawanie elementu 
losowości do celowania, np. po znacznej zmianie wektora celowania obracany jest on o pewien 
losowy kąt, który zmniejsza się wraz z czasem, gdy bot dłużej celuje w ten punkt. Szybkość tej 
zmiany określa parametr, kontrolujący celność danego bota. 

Dobre przemieszczanie się na planszy jest ważnym czynnikiem, decydującym o 
skuteczności gry. Parametr decydujący o sprawności poruszania się wpływa na sposób wyboru 
Ścieżek, którymi poruszają się boty. Parametr ten wpływa też na algorytm wyboru punktów do 
prowadzenia ostrzału. 

Innym ważnym aspektem rozgrywki botów, który może być wyrażony za pomocą 
parametrów, jest styl rozgrywki botów. Parametr ten nie przekłada się bezpośrednio na trudność 
rozgrywki botów, ale na sposób jej prowadzenia. Gry FPS nie są grami, w których jest 
znana strategia wygrywająca dla każdej planszy. Wiele zależy od zręczności lub po prostu 
szczęścia. Twórcy botów symulują u botów takie czynniki jak skłonność do ryzyka, osobowość 
emocjonalna czy też preferencje odnośnie stylu gry — każda z nich ma wpływ na akcje, 
podejmowane przez każdego bota podczas gry. Parametry takie często generowane są losowo, 
aby boty uczestniczące w rozgrywce cechowały się zróżnicowanym zachowaniem i dzięki 


czemu gra z nimi była ciekawsza. 


3.2.3. Punkty nawigacyjne 


W grach FPS bardzo ważną rolę odgrywa efektywne poruszanie się po planszy — 
zdecydowana większość akcji podejmowanych przez graczy dotyczy ruchu. Decyzje dotyczące 
ruchu tworzą bardziej skomplikowane zachowania, takie jak ucieczka przed przeciwnikami lub 


przemieszczenie się do wybranego miejsca na planszy. 
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Waypoint Information: 


Waypoint 297 of 313, Radius: 0.0 
Flags: (none) 


Experience Info: 
CT: -1/0 
T: -170 


Facing Waypoint Information: 


Waypoint 54 of #43) Radius: 16/0 


Flags: (none) 





p > 


Rysunek 3.4. Wizualizacja punktów nawigacyjnych (zielone) w widoku projektanta botów w grze 
Counter-Strike. 





Rysunek 3.5. Wizualizacja punktów nawigacyjnych (żółte) w edytorze map WorldCraft [35] w grze 
Half-Life. 


Wśród wielu botów, w tym komercyjnych, wiedza na temat planszy, na której toczy 


się rozgrywka, jest reprezentowana za pomocą punktów nawigacyjnych (ang. waypoints). 
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Wizualizacja punktów nawigacyjnych została przedstawiona na rysunkach 3.4 i 3.5 — jest to 
widok dostępny dla twórców planszy, którzy mogą tworzyć punkty nawigacyjne dla botów 
mających grać na planszy. Podczas normalnej rozgrywki punkty nawigacyjne są niewidoczne 
dla gracza, lecz boty korzystają z nich do poruszania się po planszy. 


Cechą wspólną wszystkich rodzajów punktów nawigacyjnych jest osadzenie ich w 











rzestrzeni R” oraz relacja sąsiedztwa punktów nawigacyjnych. Dzięki temu tworzą one 
p J p gacyjny 





graf nawigacyjny dla danej planszy. Boty, chcąc przejść do wybranego przez siebie punktu 
na planszy, generują Ścieżki składającą się z punktów nawigacyjnych. Z tego powodu 
graf nawigacyjny powinien być skonstruowany tak, żeby generowane Ścieżki nie zawierały 
przeszkód, których bot nie będzie w stanie później przejść. Do wyszukiwania ścieżek 
programiści botów często korzystają z algorytmu A* [57]. Boty zazwyczaj znajdują trasy, które 
minimalizują czas przejścia, maksymalizują bezpieczeństwo lub są wynikiem kompromisu 
między tymi dwiema cechami. 

Sposób wykorzystania danych z grafu nawigacyjnego jest silnie zależny od implementacji 
botów. Na ogół punkty nawigacyjne wykorzystywane są do tworzenia Ścieżek między punktami 
na planszy. Jednakże trajektoria ruchu botów nie jest łamaną łączącą punkty nawigacyjne. 
Przebiega ona jedynie w ich pobliżu, ponieważ boty uwzględniają też inne czynniki w 
planowaniu trajektorii ruchu niż sama Ścieżka złożona z punktów nawigacyjnych. Tymi 
czynnikami mogą być, na przykład: 

— zajmowanie przestrzeni przez inne postacie na planszy, 
— współpraca botów, 
— przeszkody terenowe wymagające niewielkiej korekty ruchu (np. skoku). 

Stwierdzenie, czy postać w grze może przejść między dwoma punktami, jest tym 
trudniejsze, im więcej akcji ma do wyboru, np. w grze Counter-Strike plansza może być 
modyfikowana przez otwieranie drzwi lub rozbijanie okien. Istnieją też obszary, w których 
postać może poruszać się inaczej niż chodząc, np. poprzez pływanie w wodzie lub wspinanie 
się po drabinie. 

W zależności od implementacji botów, punkty nawigacyjne mogą zawierać dodatkowe 
atrybuty, statyczne lub dynamiczne. Statyczne atrybuty to takie, które są tworzone przez 
projektanta mapy i nie ulegają zmianie w trakcie rozgrywki, natomiast dynamiczne to takie, 
które są generowane na podstawie danych statycznych i zmieniają się w trakcie rozgrywki. 
Punkty nawigacyjne w grze Half-Life nie zawierają żadnych dodatkowych atrybutów, które 
byłyby określane przez projektanta planszy. Krawędzie grafu nawigacyjnego są generowane 
przez samą grę. Twórca punktów nawigacyjnych w grze Counter-Strike podaje dużo więcej 
informacji podczas tworzenia planszy. Dodatkowe informacje w punktach nawigacyjnych 
z jednej strony stanowią formę wskazówek dla botów, jakie decyzje mają podejmować na 


danej planszy, z drugiej strony stanowią narzędzie dla projektanta planszy do uzyskiwania 
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pożądanego zachowania botów na danej planszy. Punkty nawigacyjne dla botów w grze 
Counter-Strike zawierają m.in następujące informacje statyczne: 

— czy w pobliżu punktu znajdują się zakładnicy, 

— czy w pobliżu punktu znajduje się cel do wysadzenia przez terrorystów, 

— czy punkt nadaje się do kampowania”. 

Informacje dynamiczne są tworzone i modyfikowane podczas rozgrywki na podstawie 
informacji statycznych i danych uzyskanych w trakcie gry. Istnieją implementacje botów, 
w których zbierają one informacje na temat ilości obrażeń otrzymanych w pobliżu punktów 
nawigacyjnych, w celu planowania bezpiecznych ścieżek, którymi następnie będą się poruszać. 
Sam graf nawigacyjny może być dynamiczny, tzn. ilość i rozmieszczenie punktów 
nawigacyjnych może ulegać zmianie podczas rozgrywki. Przykładowo boty JoeBot XP 
[33] potrafią zmieniać rozmieszczenie i atrybuty punktów nawigacyjnych poprzez obserwację 
graczy. 

Boty w grze Counter-Strike w wersji 1.6 posiadają opcję generowania wszystkich danych o 
punktach nawigacyjnych dynamicznie, w oparciu jedynie o informacje geometryczne mapy. 
Używany do tego algorytm nie jest jawny, jednak istnieją prace na temat funkcjonalnie 
podobnych algorytmów [60]. Mimo możliwości automatycznego generowania grafów 
nawigacyjnych, możliwość ręcznego ich tworzenia jest również popularna w tej wersji gry. 
Wiele map, tworzonych zarówno przez producenta, jak i społeczność graczy, zawiera stworzone 
w ten sposób dane. Świadczy to o użyteczności punktów nawigacyjnych do definiowania 
zachowania botów na planszy. 

Nawigacja w oparciu o punkty nawigacyjne sprawdza się w przypadku plansz, w których 
zostaje zachowana geometria planszy podczas rozgrywki. Nie zawsze ten warunek jest 
spełniony gdy np. plansza zawiera dużo ruchomych elementów lub może być modyfikowana 
przez postacie podczas rozgrywki. Przykładowo, oprogramowanie GeoMod [36] pozwala 
graczom na niszczenie niektórych fragmentów planszy — jest to implementowane za pomocą 


operacji CSG (Constructive Solid Geometry) [48]. 


3.3. Implementacje wybranych botów 


W rozdziale 2 zostały przedstawione różne narzędzia sztucznej inteligencji, które mogą 
być wykorzystane do implementacji algorytmów sterujących zachowaniem botów. W tym 
podrozdziale zostaną przedstawione wybrane implementacje botów z wykorzystaniem tych 
technik. 


3 taktyka defensywna stosowana w grach FPS i RTS polegająca na utrzymywaniu przez gracza pozycji 
zapewniającej taktyczną przewagę nad przeciwnikiem. 


60 


3.3.1. Boty w grze Half-Life 


W grze Half-Life można napotkać wiele rodzajów postaci, każda z nich cechuje się 
odmiennym zachowaniem. Można spotkać np. proste istoty działające reaktywnie, które 
służą jako pułapki. Bardziej skomplikowane postacie podejmują proste samodzielne działania 
atakowania gracza lub ucieczki. Najbardziej skomplikowane postacie potrafią ze sobą 
współpracować w celu pokonania gracza. W tym rozdziale zostanie omówione zachowanie 
tych ostatnich, które są zazwyczaj istotami humanoidalnymi, np. żołnierzami. 

Boty w grze Half-Life zostały zaprogramowane przez jej twórców w języku C++ z użyciem 


programowania obiektowego. Każdy bot w grze dziedziczy z klasy bazowej CBaseMonster. 





Klasa ta zawiera metodę abstrakcyjną RunAT. Implementacja tej metody odpowiedzialna jest 
za podejmowanie decyzji niskopoziomowych przez konkretnego bota. Na każdy typ bota 
przypada jedna klasa pochodna. 

Rolę obserwacji świata gry pełnią zmienne zdaniowe, które są obliczane dla każdego bota 
w każdym cyklu działania gry. W grze zaimplementowano 32 typy zmiennych zdaniowych 
i są one realizowane jako pola bitowe typu liczbowego. Dzięki temu obliczanie warunków 
zbudowanych z koniunkcji i alternatywy jest bardzo wydajne, ponieważ jest realizowane jako 
operacje bitowe na liczbach 32-bitowych. Przykładowe typy zmiennych zdaniowych zostały 
wymienione poniżej na listingu 3.1 — są to oryginalne nazwy stosowane w kodzie źródłowym 
gry Half-Life. 


Listing 3.1. Część definicji typu wyliczeniowego do realizacji zmiennych zdaniowych w 
warunkach sekwencji akcji. 
enum Condition { 
COND_NO_AMMO_LOADED, COND_SEE_ HATE, COND_SEE_FEAR, 
COND_SEE DISLIKE, COND_ENEMY_OCCLUDED, COND_ENEMY_TOOFAR, 
COND_HEAVY_DAMAGE, COND_ENEMY_FACING_ME 
Ff ess 






























































Zmienna zdaniowa COND_SEE_HATE jest prawdziwa dla danego bota, gdy widzi on 








przeciwnika, którego może zaatakować. Zmienna zdaniowa COND_HEAVY_DAMAGE jest 
prawdziwa, gdy bot został uszkodzony w stopniu zagrażającym jego dalszej egzystencji w 
Świecie gry. 

Algorytm sztucznej inteligencji do sterowania każdym botem w grze Half-Life [23] zakłada 
podział na akcje proste i akcje złożone. Te ostatnie można łączyć w sekwencje, które są 
wykonywane po kolei. Każdy typ bota, występującego w grze, posiada właściwe sobie akcje 
złożone, stany z nimi związane oraz własne reguły do generowania sekwencji akcji złożonych. 


Z, każdą sekwencją są związane warunki logiczne, służące do określania, czy powinno zostać 
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przerwane wykonywanie uprzednio wybranej sekwencji akcji. Każdy warunek moze składać 
się ze zmiennych zdaniowych oraz spójników logicznych. 

Do podejmowania decyzji, oprócz wyżej wymienionych zmiennych zdaniowych, które 
reprezentują zarazem obserwacje i przekonania bota, wykorzystuje on również cele. Cele są 
reprezentowane poprzez typ wyliczeniowy. Listing 3.2 pokazuje nazwy stosowane w kodzie 
źródłowym botów. Postać mieć w danym momencie przypisany jeden cel do realizacji. 
Przykładowo jeśli bot wybrał cel GOAL ATTACK_ENEMY, to będzie wybierał sekwencje akcji, 


w konsekwencji których będzie dążyć do unicestwienia swoich przeciwników. 


Listing 3.2. Część definicji typu wyliczeniowego reprezentującego cele botów. 


enum Goal { 
GOAL_ATTACK_ENEMY, GOAL MOVE, GOAL TAKE COVER, 
GOAL MOVE _TARGET, GOAL EAT, 
fee 





Reguły do generowania sekwencji akcji są ustalone w kodzie źródłowym w metodzie 
GetSchedule. Reguły te odwołują się do wyżej wymienionych celów i zmiennych 
zdaniowych. 

Boty wykonują jedną akcję złożoną w danym momencie, a jej reakcje na zdarzenia w 
świecie zależą od akcji, którą aktualnie wykonuje. Twórcy gry Half-Life zaimplementowali 
podział na akcje proste i złożone za pomocą techniki automatu skończonego. Ze względu na 
możliwości tworzenia sekwencji akcji jest to automat ze stosem. Fragment kodu źródłowego, 
ilustrujący użycie automatu, został przedstawiony na listingu 3.3. Pochodzi on z kodu 
źródłowego omawianych botów. Podział jest realizowany za pomocą instrukcji warunkowej 
switch. Struktura Task_t opisuje każdą akcję złożoną jaką może wykonywać bot. Struktura 
ta zawiera parametry akcji złożonej oraz jej typ, opisywany za pomocą pola iTask. 

Przedstawiony fragment kodu botów steruje botem typu CScientist. Postacie tego 


typu to naukowcy — nieuzbrojeni cywile pomagający graczowi w grze Half-Life. Akcja 








złożona realizowane przez kod za etykietą TASK_RUN_PATH_SCARED polega na ucieczce 





po ścieżce i odgrywaniu przez postać przerażenia przez okazjonalne krzyczenie. Zadanie 
TASK_HEAL polega na uzdrawianiu gracza przez zaaplikowanie mu leczniczego zastrzyku. 
Metoda CScientist: :RunTask obsługuje jedynie część akcji złożonych — widać to 
po przekazaniu sterowania do metody z nadklasy, CTalkMonster: :RunTask, w wyniku 
użycia domyślnej etykiety (default). Klasa CTalkMonster posiada akcje złożone 
właściwe dla istot, z którymi gracz może rozmawiać. 

Boty w grze Half-Life wykorzystują punkty nawigacyjne (por. 3.2.3) do poruszania się 
po planszy. Sposób Wykorzystania punktów nawigacyjnych przez boty jest zależny od typu 
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Listing 3.3. Fragment kodu botów odpowiedzialny za wykonywanie akcji złożonej. 


void CScientist::RunTask(Task_t *pTask) { 
switch (pTask->iTask) { 
case TASK _RUN_PATH_SCARED: 

if (MovementIsComplete()) 
TaskComplete (); 

if (RANDOM _LONG(0, 31) < 8) 
Scream(); 

break; 


case TASK_HEAL: 
[k o... */ 


break; 


FR ee. ef 

default: 
CTalkMonster::RunTask (pTask) ; 
break; 


bota, ponieważ różne typy postaci mają różne możliwości atakowania i przemieszczania się, 
np. niektóre z nich potrafią skakać, a inne nie. 

Niektóre postacie pełnią rolę fabularną w grze. Wchodzą one w interakcję z graczem w celu 
przekazania mu pewnych informacji o fabule rozgrywki, tj. o zdarzeniach, które zachodzą w 
Świecie gry, o roli gracza w tym Świecie, itp. Projektant planszy może definiować tego typu 
zachowania dla botów korzystając z tzw. sekwencji skryptowych*. Są to akcje bota, których 
działanie może polegać na jego przemieszczeniu w wybrane miejsce, wypowiedzenie przez nią 
uprzednio nagranego monologu lub odegranie pewnej sceny (np. naciśnięcie przycisku). Akcje 
te można łączyć w sekwencje, a zakończenie pewnego elementu sekwencji może wywoływać 


zdarzenia na planszy, np. ruch windy czy otwarcie drzwi (patrz ilustracja 3.6). 





Rysunek 3.6. Prosta sekwencja skryptowa: strażnik używa skanera biometrycznego co powoduje 
otworzenie się drzwi. 


4 ang. scripted sequences. 


Sekwencje skryptowe sq uruchamiane poprzez zdarzenia wyzwalane na planszy, np. 
wkroczenie gracza w pewien obszar, określony przez projektanta. 

Opisywane boty w grze Half-Life działają w trybie gry jednoosobowej, co skutkuje 
przyjęciem innych założeń projektowych niż w przypadku botów w grach wieloosobowych. 
Boty w rozgrywkach wieloosobowych mają zastępować człowieka. Mogą to robić grając mniej 
lub bardziej skutecznie poprzez naśladowanie różnych poziomów ludzkich zdolności. Boty w 
trybie gry jednoosobowej mają za zadanie dostarczać graczowi rozrywki, co niekoniecznie musi 
przekładać się na wierne naśladowanie ludzkiego zachowania i jego zdolności. W grze Half-Life 
istoty walczące z graczem celowo zachowują się w pewnych sytuacjach nieracjonalnie i ich 
symulowane umiejętności daleko odbiegają od ludzkich. Ma to za zadanie przede wszystkim 
zachować równowagę w rozgrywce „jeden przeciw wielu” [34], jaką jest Half-Life. 

Zaniżenie umiejętności przeciwników w grze Half-Life dotyczy przede wszystkim 
umiejętności strzeleckich. Przykładowo, pierwszy ich strzał do gracza jest zawsze chybiony 
— ma to dać graczowi szansę reakcji. Dodatkowo, boty odznaczają się bardzo słabą 
celnością. Mimo że strzelają seriami, w gracza stojącego w znacznej odległości trafiają 
zaledwie pojedyncze pociski. W rzeczywistości tor pocisku odchyla się nawet o 20” w stosunki 
do trajektorii, która spowodowałaby trafienie w gracza. Dzięki temu gracz ma szanse na 
pokonanie dużej liczby przeciwników. 

Przykładem nieracjonalnego zachowania bota jest dawanie graczowi szansy na 
zareagowanie w przypadku nieoczekiwanego spotkania gracza. Np. żołnierze zamiast strzelać, 
gdy po raz pierwszy zobaczą gracza, wydają okrzyki, żeby zwrócić na siebie uwagę (np. 
krzyczą „mam cię!”). Innym przykładem zachowania tego typu jest aktywne atakowanie 
gracza małymi grupami, tj. w przypadku, gdy gracza atakuje duży oddział żołnierzy, 
jedynie część z nich prowadzi aktywny ostrzał, reszta zaś wygląda na zajętą czymś innym, 
np. przeładowywaniem broni, szukaniem pozycji do ostrzału. Lars Linden określa takie 
zachowanie stosowaniem stylu walki kung-fu". Przeciwnicy w grze Half-Life zachowują się 
również nieracjonalnie, wycofując się chwilę przed pokonaniem gracza. Podobnie jak w 
pozostałych przypadkach chodzi o danie graczowi dodatkowych szans w starciu z wieloma 
przeciwnikami. Dodatkowo, wycofywanie się przeciwników w ostatniej chwili powoduje 


podniesienie satysfakcji gracza poprzez stworzenie wrażenia pokonania trudnego wyzwania. 


3.3.2. Boty E[POD] w grze Counter-Strike 


Pierwsza wersja botów E/POD] powstała w roku 2003. Została stworzona przez moddera 
o pseudonimie LightNinja jako rozwinięcie botów POD*, które bazują na rozwijanych w latach 
1999-2002 botach HPB”, stworzonych do gry Half-Life. Prace nad tym ostatnim zaowocowały 
> Chodzi tu raczej o nawiązanie do filmów o azjatyckich sztukach walki, niż sztukę walki samą w sobie. 


6 ang. Ping of Death 
7 ang. High Ping Bastard 
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szablonem, ułatwiającym tworzenie botów dla modyfikacji gry Half-Life. W pracach nad 
ulepszaniem botów E/POD] brało udział wielu innych graczy. Oprogramowanie to było 
rozwijane do roku 2006, czyli jeszcze dwa lata po wydaniu wersji gry Counter-Strike, w której 
nie mogło działać. Świadczy to o dużej popularności tych botów i chęci społeczności do pracy 
nad nimi, co wyróżnia je spośród pozostałych botów. W ich implementacji zastosowano zabiegi 
poprawiające czytelność kodu źródłowego — zastosowano obiektowość i podział na przestrzenie 
nazw. Duża ilość pracy włożona w rozwój tych botów czyni też je bardzo rozbudowanymi i 
bogatymi w różne funkcje. 


Algorytm sterujący zachowaniem botów przechowuje w pamięci operacyjnej informacje o 





każdym z botów. Dane te są reprezentowane za pomocą klasy o nazwie EPODbot. Zawiera 
ona informacje na temat położenia bota, jego uzbrojenia, ilości punktów życia (HP), itp. 

Boty E/POD] są wykonane w oparciu o architekturę Brooksa [69]. W danym momencie 
mogą wykonywać jedną z 18 akcji złożonych. Akcje te są implementowane jako podklasy 
Task. Jednak logika działania akcji jest tak naprawdę zawarta w głównej pętli logiki botów. 


Przedstawiono to na listingu 3.4. 


Listing 3.4. Fragment kodu bota E/POD] odpowiedzialny za wykonywanie akcji złożonej. 
void BotThink(EPODbot* pBot) { 
































CEF 
switch (pBot->getTask() .getTaskType()) { 
case TASK_NORMAL: 
KERE 
case TASK_ENEMYHUNT: 
PORE 
case TASK _SEEKCOVER: 
[lez 


Funkcja Bot Think jest odpowiedzialna za podejmowanie decyzji niskopoziomowych 
dla bota, którego opis jest parametrem tej metody (argument pBot). Funkcja ta jest 


odpowiedzialna za wykonywanie akcji złożonej oraz jej ewentualną zmianę. Informacje 





o akcji złożonej są zawarte w strukturze Task, która jest składową klasy EPODBot. 





Metoda EPODBot: :getTask daje dostęp do obecnie realizowanej akcji złożonej. Na 
przedstawionym listingu (3.4) widać instrukcję warunkową switch, która różnicuje działanie 
kodu w zależności od wykonywanej przez bota akcji złożonej. Jest to realizacja podziału 
na akcje złożone. Użycie takiej organizacji kodu, za pomocą instrukcji switch, może 
być symptomem złego stylu projektowania obiektowego [16]. W tym przypadku bardziej 
zasadne byłoby użycie polimorfizmu. Wtedy kod, odpowiedzialny za wykonanie każdej 
z akcji złożonej, mógłby być wydzielony do osobnej klasy i kod akcji mógłby spełniać 


zasadę otwarte-zamknięte [38], tj. dodanie nowej akcji polegałoby na zaimplementowaniu 
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nowej klasy pochodnej klasy Task. Co gorsza sposób programowania podziału na 





akcja proste i złożone u botów E/POD] prowadzi to występowania w klasie EPODBot 
składowych, które mają sens jedynie w przypadku wykonywania konkretnej akcji złożonej, 
np. składowa pShootBreakable jest wykorzystywana jedynie w zadaniu usuwania 
zniszczalnych elementów planszy — Shoot BreakableTask. Tego typu podział na oddzielne 
klasy dla metod i danych jest antywzorcem programowania obiektowego znanym pod nazwą 
znawca i wykonawce? [1]. Występowanie tego antywzorca jest szczególnie częste w projektach 
wykorzystujących programowanie obiektowe bazujących na kodzie źródłowym pisanym 
wcześniej strukturalnie. W przypadku botów E/POD] taka sytuacja miała miejsce, ponieważ 
bazuje on na bocie POD, który był tworzony w strukturalnym paradygmacie programowania. 

Boty E/[POD] wykorzystują graf nawigacyjny (por. 3.2.3) w celu poruszania się po planszy. 
Przykładowy graf nawigacyjny wykorzystywany przez boty E/POD] jest zaprezentowany 
na rysunku 3.7. Graf ten pochodzi z planszy cs_747, na której oddział antyterrorystów 
ma za zadanie odbić zakładników, przetrzymywanych przez terrorystów w samolocie typu 
Boeing 747. Boty E[POD] korzystają z punktów nawigacyjnych, zawierających informacje o 
ważnych lokalizacjach dla każdej z drużyn. Zapisują one w każdym z punktów nawigacyjnych 
informacje o ilości obrażeń otrzymanych przez boty podczas przebywania w pobliżu danego 
punktu. Następnie informacje te wykorzystują do planowania działań na planszy, np. wybierają 
punkty dogodne do przeprowadzenia ataku. 

Bot, w celu dokonania wyboru Ścieżki, wzdłuż której będzie się przemieszczać, posługuje 
się grafem ważonym. Wagi są tworzone na podstawie odległości między punktami 
nawigacyjnymi oraz odnotowanej ilości obrażeń, otrzymanych przez postacie w pobliżu danego 
punktu nawigacyjnego. W ten sposób programista botów E/POD] próbował zachować 
kompromis między długością i bezpieczeństwem Ścieżek. Jest to również prosty mechanizm 
adaptacji — jeżeli przeciwnik stosuje taktykę, w której pewne Ścieżki są bardziej niebezpieczne 
dla bota niż inne, to procedura wyboru uwzględni ten fakt. 

Informacje o obrazeniach, otrzymanych w pobliżu punktów nawigacyjnych, 
wykorzystywane są nie tylko do wyboru ścieżek do przemieszczania się, ale również do 
wyboru punktów do prowadzenia ostrzału, ochrony obszarów i ukrywania się. Do prostego 
wyszukiwania Ścieżek, z pomięciem statystyk o obrażeniach. Przykładowo, w celach 
wizualizacji w interfejsie projektanta mapy, wykorzystywany jest algorytm Floyda-Warshalla 
[11]. Algorytm ten służy do wyszukiwania najkrótszych ścieżek w grafie ważonym między 
wszystkimi parami wierzchołków. Jest on uruchamiany jeden raz podczas wczytywania mapy 
i następnie jest wykorzystywany wynik jego działania. 

Boty E[POD] mogą wybierać zadania reaktywnie, w odpowiedzi na zdarzenia rozgrywające 


się w Świecie gry, lub w procesie deliberacji, poprzez reguły wnioskowania zapisane w kodzie 


8 ang. Doer and Knower 
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Rysunek 3.7. Graf nawigacyjny dla planszy cs_747 


źródłowym algorytmu sterowania botami. Bot ma możliwość przerwania wykonania bieżącej 
akcji złożonej w celu zastąpienia jej inną akcją złożoną. Po wykonaniu akcji przerywającej, 
bot może wznowić akcję, która została przerwana. Do zapamiętywania przerwanych akcji bot 
posługuje się stosem (zob. 2.2.2). Nie ma jednak mechanizmu pozwalającego na tworzenie 
sekwencji akcji, podobnego do tego, którymi dysponują boty w grze Half-Life, przedstawionego 
w rozdziale 3.3.1. Po zakończeniu aktualnego zadania bot wznawia akcję, która znajduje się 
na stosie, lub szuka nowej za pomocą reguł zapisanych w kodzie źródłowym. Z tego powodu 
wszystkie zachowania bota, będące sekwencjami akcji złożonych, są wynikiem odpowiedniego 
doboru przez programistę reguł wyboru tychże akcji. 

W wyniku działania wnioskowania reaktywnego może pojawić się kilka akcji złożonych, 
które mogą być potencjalnie wykonane przez bota jako odpowiedź na czynnik, który wyzwolił 
to wnioskowanie. Przykładowo, w przypadku zaatakowania bota, może pojawić się zadanie 
zaatakowania napastnika, szukania osłony lub ucieczki. Jeżeli pojawia się wiele zadań 
możliwych do wyboru, to bot wybiera jedno spośród nich poprzez przypisanie możliwym do 
wyboru zadaniom parametru liczbowego, który można interpretować jako „chęć” wykonania 


zadania, oraz wybór zadania o najwyższej wartości tego parametru. 
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Reguły wnioskowania bota dotyczą m.in. parametrów reprezentujących „cechy 
osobowości” i „emocje? postaci. Cechy osobowości są właściwościami bota, które nie 
ulegają zmianie podczas rozgrywki. W przypadku botów E/POD] wyróżnia się następujące 
cechy osobowości: odwaga, inteligencja, opanowanie i refleks. Wszystkie z przedstawionych 
właściwości są reprezentowane za pomocą atrybutów liczbowych. W przypadku botów 
E[POD] można mówić, np. o poziomie odwagi czy też o poziomie refleksu botów. Wyższy 
parametr odwagi zwiększa preferencje do podejmowania przez bota akcji ofensywnych przy 
niższych szansach powodzenia (np. atakowania w przypadku braku kamizelki kuloodpornej). 
Parametr inteligencji wypływa na różnorodność taktyk stosowanych przez bota w rozgrywce. 
Bot z wyższą wartością tego parametru wykorzystuje więcej taktyk w rozgrywce. Opanowanie 
jest czynnikiem, który reguluje szybkość zmian parametrów symulujących emocje bota. Mniej 
opanowany bot reaguje gwałtowniej zmianami poziomu strachu i agresji, ale szybciej też 
te emocje wracają do swojego bazowego poziomu. Refleks jest zdolnością do szybkiego 
reagowania na zmiany w Środowisku gry. Od parametru tego zależy czas, jaki upływa między 
zajściem zdarzenia w Świecie gry, a podjęciem przez bota akcji w odpowiedzi na nie. 

Niektóre akcje złożone są wykonywane tylko przez boty, które posiadają odpowiednie 
wartości parametrów reprezentujących cechy osobowości. Przykład takiego zachowania, 
polegającego na skradaniu się do przeciwnika, został przedstawiony na listingu 3.5. Na 


przykładzie widać, że w tym zachowaniu bot porusza się poprzez czołganie się — jest 








to realizowane poprzez uaktywnienie flagi IN_DUCK. Zachowanie to występuje tylko 
w przypadku realizowania akcji TASK _ENEMYHUNT, która polega na pościgu i próbie 
wyeliminowania przeciwnika. (Opisane zachowanie jest dostępne tylko dla botów z 


odpowiednimi wartościami parametrów refleksu i odwagi”. 


Listing 3.5. Dodatkowe zachowanie zależne od charakterystyki postaci. 





case TASK _ENEMYHUNT: 
if (pBot->Re + 2 x pBot->In > 42) { 
ffars 
pEdict->v.button |= IN_DUCK; 














Pewne parametry botów, związane z modelem decyzyjnym, ulegają zmianom podczas 
rozgrywki. Parametry te symulują emocje bota: gniew i strach. Gniew jest parametrem, 
który zwiększa preferencje używania akcji ofensywnych przez bota. Natomiast strach jest 
parametrem, który zwiększa preferencje wybierania akcji defensywnych, mających na celu 
zapewnienie przeżycia. 

Zmiany wartości tych parametrów są wyzwalane przez zdarzenia w świecie gry, np. 
dostrzeżenie przeciwnika. Zdarzenia te zwiększają wartości parametrów gniewu lub strachu 


? Wybór przez autora jako progu liczby 42, znanej w kulturze popularnej jako Odpowiedź na najważniejsze 
pytanie o życiu, wszechświecie i wszystkim, może Świadczyć o arbitralnym wyborze autora. 
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(tj. „wyzwalają emocje”). Po pewnym czasie wartości tych parametrów wracają do swoich 
poziomów bazowych (bot „uspokaja się”). Prędkość tej zmiany zależy o właściwości opisującej 
opanowanie postaci. Listing 3.6 przedstawia parametry liczbowe w kodzie źródłowym bota 
reprezentujące emocje postaci i ich poziomy bazowe: fFearLevel to poziom strachu, 


a fBaseFearLevel to poziom bazowy strachu. Analogicznie, fAgressionLevel 





to poziom agresji, a fBaseAgressionLevel to poziom bazowy agresji. Komentarze 





do zaprezentowanych na listingu składowych są oryginalnymi komentarzami autora botów 
E[POD]. 


Listing 3.6. Implementacja parametrów bota odpowiedzialnych za emocje 


class EPODbot { 
float fBaseAgressionLevel; // Base Levels used when initializing 





float fBaseFearLevel; 
float fAgressionLevel; // Dynamic Levels used ingame 








float fFearLevel; 


Ostatnią z opisanych w tym rozdziale właściwości postaci jest typ osobowości 
emocjonalnej. Jest to właściwość, która, w przeciwieństwie do poprzednich, nie jest wyrażana 
za pomocą wartości liczbowej, lecz jest atrybutem nominalnym, realizowanym jako typ 
wyliczeniowy. Właściwość reprezentująca osobowość emocjonalną jest ściśle powiązana z 
funkcjonowaniem emocji u botów E/POD]. Można wyróżnić 3 typy tych osobowości: lękliwą, 
nerwową i zrównoważoną. Bot z osobowością lękliwą, jeśli zostanie zaatakowany, to zawsze 
reaguje zwiększeniem poziomu lęku. Boty z takim typem osobowości preferują podczas 
rozgrywki taktyki defensywne. Zaatakowany bot z osobowością nerwową, zawsze reaguje 
zwiększeniem poziomu gniewu. Takie boty preferują ofensywne taktyki rozgrywki. Natomiast 
zaatakowany bot z osobowością zrównoważoną reaguje zwiększeniem poziomu gniewu lub 
strachu w zależności od ilości punktów życia (HP) jakimi dysponuje. Duża ilość punktów 
życia zazwyczaj oznacza zwiększenie poziomu gniewu, a niska — poziomu strachu. 

Najczęściej wykonywaną akcją złożoną jest NormalTask — polega ona na próbie 
realizowania jednego z czterech celów, zależnego od typu planszy, lub wspierania innych 
graczy w drużynie w działaniach zmierzających do osiągnięcia tego celu, np. poprzez 
kampowanie. Nie ma w tym wypadku reguł, opisujących współpracę pomiędzy botami i 
zachowania zespołowe mają raczej emergentny charakter. Wybór pomiędzy kampowaniem, 
atakowaniem przeciwnej drużyny 1 innymi akcjami jest w dużej mierze losowy — przykładowy 
fragment kodu losującego cele został przedstawiony na listingu 3.7. Pochodzi on z kodu 
realizującego akcję złożoną NORMAL_ TASK. 

Na przedstawionym listingu zmienna iTactic jest dodatkowym parametrem akcji 


określającym typ celów do wyboru. Mogą być to cele związane z realizacją celu 
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Listing 3.7. Implementacja wyboru losowego celu do wykonania. 


// Map Goal Waypoint 
else if (iTactic == MAP _ GOAL) { 
for (i = 0; i < 4; itt) { 
iGoalChoices[i] = 
g_rgiGoalWaypoints [RANDOM_LONG(0, g_iNumGoalPoints) ]; 








właściwego dla danej planszy, wtedy zmienna ta przyjmuje wartość MAP_GOAL. Inne 
możliwe do wyboru wartości tej zmiennej powodują wybór celów prowadzących do eliminacji 
drużyny przeciwnej, lub też, utrudniania drużynie przeciwnej realizacji jej celów. Globalna 
tablica g_rgiGoalWaypoints, o długości g_iNumGoalPoints, zawiera identyfikatory 
punktów nawigacyjnych, które są celami planszy, np. mogą to być miejsca, gdzie 


przetrzymywani są zakładnicy lub miejsca gdzie terroryści mają podłożyć bombę. Makro 





RANDOM_LONG służy do losowania liczby całkowitej z danego zakresu. Przedstawiony 
fragment kodu służy do wyboru czterech punktów nawigacyjnych, istotnych dla realizacji celów 
rozgrywki. Rozpoczynając wykonanie akcji złożonej NORMAL_ TASK bot losuje cztery cele za 
pomocą zaprezentowanego wyżej kodu, a następnie wybiera jeden z nich na podstawie swoich 
preferencji. 

Podstawową formą współpracy pomiędzy botami jest podążanie za postacią, która pełni 
rolę przywódcy, i wspieranie jej w walkach. Akcja ta jest realizowana za pomocą klasy 
FollowPlayerTask. Boty E/POD] tworzą drużyny dzięki mechanizmowi komunikacji. 
Wykorzystują one mechanizm komunikacji radiowej, który stanowi składnik gry Counter-Strike 
i jest dostępny również dla gracza. Dzięki temu gracz ma możliwość odnotowania faktu, że 
boty tworzą drużynę, ponieważ słyszy ich komunikację. Gracz może też zaproponować, że 
sam będzie przywódcą. W tym celu wydaje odpowiedni komunikat (np. komendę „Follow 
me”"0). Usłyszenie komunikatu radiowego wywołuje u bota reakcję, która może prowadzić do 
pojawienia się nowej akcji złożonej do wykonania przez niego. Fragment kodu odpowiedzialny 
za reakcję na usłyszenie komunikatu ,,Follow me” przez bota został przedstawiony na listingu 
3.8. 


Listing 3.8. Implementacja reakcji na przykładowy komunikat radiowy. 


switch (pBot->iRadioOrder) { 
case RADIO_FOLLOWME: 
(fosa 
pBot->addTask (FollowPlayerTask (pPlayer) ); 
break; 


LY Bac 





10 ang. za mną! 
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Zmienna pBot oznacza bota, który przetwarza komunikat radiowy. Atrybut bota 


iRadioOrder jest typu wyliczeniowego, który opisuje wszystkie typy wiadomości, dostępne 





w komunikacji radiowej w grze Counter-Strike. Po otrzymaniu informacji o nadaniu 
komunikatu bot sprawdza, czy powinien na ten komunikat reagować, np. czy nie zareagował 
już na podobny komunikat tego typu, czy nie wykonuje ważniejszej akcji złożonej itp. Jeżeli 
w wyniku sprawdzenia zostanie podjęta decyzja o reakcji na komunikat „Follow me”, to 
bot odkłada akcję złożoną FollowPlayerTask na stosie zadań do wykonania. Akcja ta 
powoduje wyżej opisane podążanie bota za inną postacią w grze. W przypadku reakcji na 
komunikat „Follow me” bot podąża za nadawcą tego komunikatu — może to być inny bot lub 
postać gracza. 

Wadą sposobu współpracy botów E/POD] jest fakt, że drużyny rozpadają się szybko i 
boty zaczynają działać pojedynczo. Wynika to ze sposobu funkcjonowania akcji złożonej 
FollowPlayerTask. Bot podąża za przywódcą jedynie w linii prostej, ignorując wszelkie 
przeszkody. W przypadku stracenia z pola widzenia przywódcy akcja jest natychmiast 
przerywana i w konsekwencji bot odłącza się od drużyny. 

Istotnym czynnikiem, który wpływa na decyzje bota, jest posiadana przez niego broń. Boty 
posiadające broń snajperską preferują kampowanie i taktyki defensywne, podczas gdy boty 
korzystające z broni ciężkiej preferują taktyki ofensywne. Zmiany w preferencjach botów w 
tym przypadku odbywają się poprzez manipulowanie ich cechami osobowości, w szczególności 
parametrami odwagi. 

Nie wszystkie akcje złożone, które może wykonywać postać, służą do realizacji jej celów 1 
celów drużyny. Np. akcja złożona BlindedTask polega na symulowaniu reakcji na granat 
hukowy. Reakcja ta polega na niedostrzeganiu przeciwników i panicznych zachowaniach, np. 
strzelanie „na ślepo”. W przypadku człowieka takie zachowanie jest efektem utracenia wzroku 
na pewien krótki czas. Ze względu na wspomniany wcześniej odmienny sposób postrzegania 
przez boty otoczenia gry, takie zachowanie jest symulowane na poziomie akcji wykonywanej 


przez bota, a nie ingerencji w działanie jego sensorów. 


3.3.3. Boty RhoBot w grze Deathmatch Classic 


Gra Deathmatch Classic jest grą z rodziny Half-Life. Jej rozgrywka toczy się w trybie 
deathmatch oraz team deathmatch. W rozgrywce w trybie deathmatch zadaniem każdego 
z graczy jest eliminacja innych uczestników rozgrywki. Do realizacji tego celu gracz może 
zbierać broń znajdującą się na planszy i tzw. power-upy, np. pancerz lub chwilowe zwiększenie 
siły ognia postaci. Każde wyeliminowanie przeciwnika powoduje przyznanie punktu, a 
wyeliminowana postać wraca natychmiast do gry. W tego typu rozgrywce nie ma podziału 
na drużyny, tzn. każdy gracz gra samodzielnie. Podział na drużyny występuje natomiast w 


rozgrywce w trybie team deathmatch. W tym trybie gracze nie eliminują siebie nawzajem w 
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obrebie druzyny, a punkty przyznawane sa druzynowo. Cel pozostaje natomiast taki sam — 
eliminowanie graczy z przeciwnej druzyny. 

Realizm gry Deathmatch Classic jest mniejszy niż gry Counter-Strike: postacie poruszają 
się dużo szybciej i są w stanie wytrzymać więcej obrażeń od pocisków. Czyni to rozgrywkę 
bardziej dynamiczną w stosunku do Counter-Strike. Obecnie istnieje dużo gier FPS o podobnej 
mechanice. Najbardziej znanymi przykładami mogą być Unreal lub Quake III. Jako przykład 
botów grających w tego typu grę zostaną omówione boty RhoBot, grające w grę Deathmatch 
Classic. 

Podobnie jak boty E/POD], boty RhoBot są stworzony w języku C++. Jednak w tym 
przypadku autorzy wykorzystali w większym stopniu programowanie obiektowe. 

Klasa reprezentująca bota nosi nazwę CBaseBot. Niemal wszystkie funkcje, z jakich 
korzysta bot, są metodami tej klasy CBaseBot. Znajduje się tam również metoda 
odpowiedzialna za podejmowanie decyzji dla bota. 

Inne ważniejsze pomocnicze klasy to: 

— CBaseBotMemory - odpowiedzialna za zapamiętywanie zdarzeń na planszy, 

— CBaseBotFightStyle -odpowiedzialna za używanie broni, 

— CBaseBotStats -odpowiedzialna za parametry bota, np. symulujące cechy osobowości, 

podobnie jak w przypadku botów E/POD]. 

Sama klasa CBaseBot zawiera dużo metod łączących odpowiedzialność z różnych zakresów: 
poruszania się, reaktywności czy też wnioskowania deliberatywnego. Jest to przykład klasy 
określanej w inżynierii oprogramowania mianem God-object, ponieważ klasa ta łączy w sobie 
wiele różnych, niezwiązanych ze sobą, rodzajów odpowiedzialności. 

Podobnie jak boty E/POD], boty RhoBot poruszają się po planszy wykorzystując 
punkty nawigacyjne, z tym że boty RhoBot mają możliwość dynamicznego generowania 
punktów nawigacyjnych podczas rozgrywki. Boty RhoBot są wykonane w oparciu o 
architekturę Brooksa — można u nich wyodrębnić akcje proste i złożone. Wykonują akcje 
złożone, polegające na zbieraniu przedmiotów z planszy, szukaniu i atakowaniu przeciwnika, 
kampowaniu czy też uciekaniu. Do wyboru tych akcji używają wnioskowania deliberatywnego 
oraz reaktywnego. 

Podział na akcje proste i złożone jest zaimplementowany za pomocą automatu skończonego. 
Bot wybiera akcje złożone poprzez stosowanie funkcji użyteczności dla każdej możliwej do 
wykonania akcji. Wybiera on akcję o najwyższej wartości funkcji użyteczności. Wartość 
funkcji użyteczności jest określana przez programistów botów RhoBot jako poziom motywacji 
do wykonania danej akcji złożonej. Przykładowo, dla akcji zebrania przedmiotu z planszy 
użyteczność zależy od odległości od tego przedmiotu. Jeżeli bot rozpatruje akcję zebrania 


apteczki, to przy obliczaniu funkcji użyteczności bierze pod uwagę ilość posiadanych punktów 
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życia (HP). W przypadku akcji zbierania amunicji, bierze pod uwagę ilość posiadanej amunicji. 
Dzięki temu jest w stanie priorytetyzować przedmioty, które zamierza zebrać. 

Bot może wykonywać jednocześnie akcje związane z celowaniem i strzelaniem oraz 
poruszaniem się. W przypadku wnioskowania deliberatywnego, do wyboru akcji z obu kategorii 
bot posługuje się dwoma odrębnymi drzewami decyzyjnymi. Drzewa te zostały stworzone przez 
programistę botów RhoBot w oparciu o jego wiedzę oraz stosowanie metody prób i błędów. 
Drzewa decyzyjne są reprezentowane za pomocą instrukcji kodu źródłowego w C++ i są one 
kompilowane do kodu maszynowego wraz z całym sterownikiem botów. Stanowią one składnik 
botów RhoBot i nie mogą być zmieniane inaczej, niż poprzez ponowne skompilowanie kodu 
botów. Schematy tych drzew zostały przedstawione na rysunkach 3.8 i 3.9. Węzły o kolorze 
białym oznaczają wykonanie akcji złożonej, natomiast węzły o kolorze szarym wykonanie testu 
w drzewie decyzyjnym. Opis testu w węzłach wewnętrznych drzewa wyraża sens testu, który 


w kodzie źródłowym botów sprowadza się do wykonaniu wielu instrukcji. 


SteerSafePursue () 


























SteerSafeFl () 








SteerSafeGoal( GetGoal() ) 


SteerSafeWanderImproved () 

















SteerSafeGoal( GetGoal() ) 














SteerSafeWanderImproved () 


Rysunek 3.8. Drzewo decyzyjne do wyboru akcji ruchu dla botów RhoBot. 


Warunki sprawdzane w węzłach wewnętrznych drzewa to: 
— Enemy is alive? — spełniony, jeżeli żyje przeciwnik, z którym walczy bot; 


— Enemy is visible? — spełniony, jeżeli bot widzi przeciwnika, z którym walczy; 
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Rysunek 3.9. Drzewo decyzyjne do wyboru akcji związanych z używaniem broni dla botów RhoBot. 















— Has decent weapon? — spełniony, jeżeli bot posiada broń uznawaną za skuteczną (w 
kodzie źródłowym jest wyspecyfikowana lista takich broni); 
— Want to be in combat? — warunek, który zależy od wielu czynników, 


charakteryzujący chęć bota do podjęcia walki; 





Remember enemy position? — spełniony, jeżeli bot posiada informacje o ostatnim 


znanym położeniu przeciwnika; 








— Not remember enemy position? — zaprzeczenie warunku Remember enemy 
position?; 

— Has goal? — spełniony, gdy bot ma cel do zrealizowania, np. zebranie apteczki; 
Akcje złożone, które są wybierane za pomocą drzewa, to: 


SteerSafePursue — pościg za przeciwnikiem i próba jego eliminacji; 








SteerSafeSeek — poszukiwanie przeciwnika; 


— SteerSafeEvade — unikanie walki z przeciwnikiem; 





SteerSafeF lee — ucieczka w bezpieczne miejsce; 





SteerSafeGoal — ruch do celu określonego parametrem, np. miejsca na planszy gdzie 


znajduje się amunicja; 








SteerSafeWanderImproved — losowe wędrowanie po planszy; 

— ActionOpenFire — strzelanie do przeciwnika; 
— ActionChooseWeapon — wybór i ewentualna zmiana broni. 

Wykonanie akcji prostej u botów RhoBot polega na przesłaniu do silnika gry Half-Life 
informacji o wektorze, wzdłuż którego bot będzie się poruszać, wektorze, wzdłuż którego 
będzie celować, oraz innych informacji, które gracz przesyła za pomocą kontrolerów gry (np. 
klawiatury). Są to m.in. informacje o tym, czy bot oddaje akurat strzał, czy kuca, czy zmienia 
broń na inną — każdej z tych informacji odpowiada pewien przycisk na klawiaturze, np. 
wciśniecie przycisku ,,CTRL” przez gracza powoduje oddanie strzału przez sterowaną przez 
niego postać. 

Koordynacja wykonania dwóch różnych typów akcji złożonych (ruch i celowanie) polega 


na tym, że wykonanie akcji każdego z tych typów powoduje częściowe określenie akcji prostej. 
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Akcje złożone, związane z poruszaniem się po planszy, powodują wybór wektora ruchu i 
określanie czy bot skacze, kuca, itp. Natomiast akcje związane z celowaniem powodują wybór 
wektora, wzdłuż którego bot będzie celować, i określenie, czy oddaje w danym momencie 
strzał. 

Akcje złożone mogą być zmieniane przez wnioskowanie deliberatywne, które jest 
przeprowadzane w odstępach od 0.1 do 0.5 sekundy, w zależności od parametrów bota. 

Bot RhoBot ma możliwość reagowania na zdarzenia zachodzące w Świecie gry np. 
zaatakowanie go przez innego uczestnika rozgrywki. Działania reaktywne są implementowane 
za pomocą sprawdzania zestawu warunków, które symulują percepcję bota. W tym wypadku 
również zostały użyte reguły w postaci drzewa decyzyjnego. Wraz z wnioskowaniem 
deliberatywnym mogą one prowadzić do próby równoczesnego wykonania wzajemnie 
wykluczających się akcji. Taki konflikt jest rozwiązywany poprzez przypisanie akcjom 
priorytetów. W przypadku akcji nawigacyjnych priorytet akcji jest typem wyliczeniowym (zob. 
listing 3.9 pochodzący z kodu źródłowego bota RhoBot). 


Listing 3.9. Priorytety dla akcji nawigacyjnych 
typedef enum { 
STEER_WANDER, STEER_WANT_ITEM, 
EER_GROUP_ASSEMBLE, STEER_WANT_ENEMY, 
EER_GROUP_BOT, STEER_GROUP_HUMAN, 
EER_SURVIVAL 
EER; 
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Wartości typu wyliczeniowego z listingu 3.9 oznaczają odpowiednio: STEER_WANDER 





- poruszanie się w celu przeszukiwania planszy, STEER_WANT_ITEM - poruszanie 





się w celu zebrania przedmiotu, STEER_GROUP_ASSEMBLE - poruszanie się w 


celu sformowania grupy, STEER_WANT_ENEMY - poruszanie się podczas walki z 





przeciwnikiem, STEER_GROUP_BOT - poruszanie się w grupie sformowanej przez 
bota, STEER_GROUP_HUMAN - poruszanie się w grupie sformowanej przez gracza, 
STEER_SURVIVAL - ucieczkę. 





Porządek wartości typu wyliczeniowego STEER jest zdefiniowany zgodnie ze specyfikacją 


języka C++. Ten porządek wartości określa priorytet akcji nawigacyjnych, tj. akcja 








STEER_WANDER ma najmniejszy priorytet, natomiast akcja STEER_SURVIVAL — 


największy. 





Priorytety STEER_GROUP_HUMAN, STEER_GROUP_BOT oraz 





STEER_GROUP_ASSEMBLE występują wyłącznie w rozgrywce typu team deathmatch. 
Dla większości priorytetów reguły decyzyjne bota skonstruowane są tak, że nie jest możliwy 


równoczesny wybór dwóch akcji o takim samym priorytecie. Jednak dla priorytetów 





STEER_WANT_ENEMY i STEER_SURVIVAL jest to możliwe. W takim przypadku bot 





agreguje wyniki działania wielu akcji złożonych o tym samym priorytecie. Dla akcji 
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ruchu polega to na agregowaniu wektorów, wzdłuż których się ma poruszać bot w ramach 


akcji prostych. Ilustracja 3.10 przedstawia sytuację, w której bot ucieka przed dwoma 





przeciwnikami. Jest to agregacja wyników działania akcji o priorytecie STEER_SURVIVAL. 


-© 


Rysunek 3.10. Przykładowa sytuacja ucieczki bota od dwóch przeciwników. 


W sytuacji przedstawionej na ilustracji 3.10 bot B3 ucieka przed dwoma przeciwnikami: Bı 


oraz Bo. Przy wyborze akcji złożonej dla bota B3 pojawiają się dwie akcje ruchu z tym samym 





priorytetem STEER_SURVIVAL, lecz o innych wektorach ruchu. Akcja ucieczki od postaci Bı 
ma wektor vı, natomiast akcja ucieczki od postaci Bə — wektor v2. Bot agreguje te dwa wektory 
obliczając ich średnią. Następnie normalizuje wynik i mnoży przez szybkość poruszania się. 
Wyznaczony w ten sposób wektor v3 jest wynikiem akcji ruchu wybranej przez bota. 


Bot korzysta również z akcji poruszania się zespołowego [49]. Są to akcje nawigacyjne 





z priorytetami STEER_GROUP_BOT oraz STEER_GROUP_HUMAN. Akcje te uwzględniają 
położenie oraz kierunek ruchu innych przyjaznych postaci w pobliżu bota. Mają one sens 
jedynie w rozgrywkach z podziałem na drużyny (tzw. team deathmatch), ponieważ w 
przypadku gry w trybie deathmatch każda postać w grze jest wroga. 

Ciekawostką wartą wspomnienia jest możliwość prowadzenia przez boty prostych dialogów 
z graczem za pomocą czatu. Funkcja ta nie wpływa w żadnym stopniu na działanie botów 
w grze. Jednak prowadzenie konwersacji przez czat jest ważnym aspektem rozrywkowym w 
grach FPS w trybie wieloosobowym. Inne boty zazwyczaj ograniczają się do wypowiadania 
określonych haseł losowo w zależności od sytuacji. Natomiast RhoBot wykorzystuje w tym 


celu algorytm ALICE [62] z bazą wzorców zdań w języku AIML. 


3.3.4. Boty MarineBot w grze Firearms 


Gra Firearms była trzecią co do popularności modyfikacją gry Half-Life — wyprzedziły 
ją jedynie Counter-Strike i Team Fortress. Gra jest symulacją walki wojsk lądowych. W 
rozgrywce gracze dzielą się na drużyny: „niebieską” i „,czerwoną”. W przeciwieństwie do 
gry Counter-Strike, rozgrywka w grze Firearms nie jest podzielona na rundy. Wyeliminowany 
gracz po pewnym czasie wraca ponownie do gry. Jednak liczba powrotów do gry przez 


graczy dla każdej drużyny jest limitowana. Ten limit jest w grze nazywany liczbą posiłków 
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dostępnych dla drużyny. W grze jest to przedstawiane w taki sposób, ze postać gracza zginęła 
i gracz wciela się w nową postać, która wkracza do walki jako wsparcie dla drużyny. Drużyny 
wykonują na planszy pewne zadania, jednak ich wykonanie nie prowadzi do natychmiastowego 
zwycięstwa, tylko zmniejsza limit posiłków drużyny przeciwnej, co przechyla szalę zwycięstwa 
na jej niekorzyść. Zadania, które może wykonywać drużyna, są zależne do typu planszy. 
Można wyróżnić następujące rodzaje plansz: Capture the Intelligence, Push, Search & Destroy, 
Teritorial Control oraz Objective. 

Na planszy typu Capture the Intelligence drużyny próbują sobie nawzajem siłą wykradać 
tajne dokumenty. Każdorazowe powodzenie kradzieży oznacza zrealizowanie zadania i 
zmniejszenie limitu posiłków okradzionej drużynie. Ten typ planszy ten przypomina popularny 
inny popularny typ plansz w grach wieloosobowych — Capture the Flag, jednak w przypadku 
gry Firearms flagi zastąpiono jednak dokumentami. Na planszach typu Push drużyny próbują 
się nawzajem „zepchnąć” z planszy poprzez zajmowania strategicznych punktów. Drużyna 
wygrywa w przypadku zajęcia wszystkich strategicznych punktów na planszy. Gra na planszach 
typu Search & Destroy polega na niszczeniu przez drużyny strategicznych obiektów, np. 
magazynów paliwa. Każdorazowa utrata strategicznego obiektu przez drużynę oznacza też 
zmniejszenie dostępnych posiłków. Rozgrywka na planszach typu Teritorial Control polega 
na zajmowaniu przez drużyny punktów kontrolnych. Drużyna, która ma pod kontrolą mniej 
punktów, stopniowo traci posiłki. Plansze typu Objective stanowią kategorię obejmującą 
pozostałe typy map, które nie pasują do powyższych kategorii. Zwykle jest to połączenie kilku 
typów planszy w jednej. 

Gra Firearms, w czasach swojej popularności, wyróżniała się na tle innych z uwagi na 
dużą ilość dostępnych podczas rozgrywki typów broni — było ich ponad 30. Inne cechy 
wyróżniające grę Firearms to umiejętności charakteryzujące postać, takie jak np. leczenie, 
używanie artylerii czy też możliwość używania na niektórych planszach spadochronu w celu 
wkraczania do rozgrywki. 

Podobnie jak Counter-Strike, gra Firearms kładzie nacisk na realizm. Jednak jest ona 
osadzona w innych realiach niż Counter-Strike, co ma wpływ na mechanikę gry oraz wygląd 
plansz. Counter-Strike jest grą, w której dominuje walka w przestrzeniach zamkniętych. 
Ekwipunek dostępny graczom jest dostosowany przede wszystkim do prowadzenia tego typu 
walki. W przypadku Firearms dominuje walka na przestrzeniach otwartych. W takich 
warunkach walka toczy się na znaczną odległość, co spowalnia nieco dynamikę gry. 

Boty MarineBot grają w Firearms. Podobnie jak w pozostałych przypadkach omawianych 
botów, tak samo MarineBot korzysta z punktów nawigacyjnych do poruszania się po planszy. 

Model decyzyjny botów został wykonany w oparciu o drzewo decyzyjne, aczkolwiek 


brakuje jasnego podziału na akcje podstawowe i akcje złożone, co powoduje znaczny rozrost 
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drzewa decyzyjnego i konieczność użycia rozbudowanych instrukcji warunkowych o różnych 
stopniach szczegółowości. 

Parametry botów to dwie zmienne liczbowe: poziom celności i poziom doświadczenia. 
Celność ma wpływ na szansę trafienia przeciwnika. Doświadczenie ma wpływ na wiele innych 
czynników, takich jak na promień sąsiedztwa, w jakim bot wyszukuje przeciwników. 

Bot MarineBot ma zaimplementowany wyraźny podział na role. Rola bota w drużynie jest 
określana w zależności od posiadanego ekwipunku i sytuacji drużyny, do której należy. Postać 
może łączyć w sobie wiele ról, są więc one zaimplementowane jako flaga bitowa. Znaczenie 


poszczególnych flag zostało przedstawione na listingu 3.10. 


Listing 3.10. Flagi dla ról bota MarineBot — fragment kodu źródłowego bota. 














define STANDARD (1<<0) // standard play 
define ATTACKER (1<<1) // more aggressive play 
define DEFENDER (1<<2) // more defensive play 


// additional behaviour info based on weapon 

define COMMON (1<<10) // common rifle 

define CQUARTER ( ) // bot with SMG 6 shotgun 
define MGUNNER (1<<12) // bot with machinegun 
define SNIPER ( ) 


























// bot with sniper rifle 














Wartości ATTACKER, DEFENDER i STANDARD dotyczą sposobu prowadzenia rozgrywki. 


Oznaczają one odpowiednio bota ofensywnego, defensywnego oraz zrównoważonego. Flagi 





bitowe COMMON, CQUATER, MGUNNER i SNIPER dotyczą używanego ekwipunku przez bota. 





Rola COMMON oznacza bota używającego karabinu szturmowego, CQUATER — broni do walki 
w przestrzeniach zamkniętych (np. strzelbę lub pistolet maszynowy), MGUNNER — karabinu 





maszynowego, zaś SNIPER — karabinu strzelca wyborowego. 

Uaktywnienie danej roli u bota powoduje, że rozważa on inne punkty nawigacyjne podczas 
tworzenia Ścieżek, po których będzie się poruszać. Każdy z punktów nawigacyjnych może 
mieć informacje, opisujące jakie role muszą mieć boty, aby mogły poruszać się w pobliżu 
tych punktów. Pozwala to na rozwiązanie problemu występującego u botów E/POD], gdzie 
zdarzają się sytuacje, w których bot postępuje nieadekwatnie do posiadanego ekwipunku, np. 
zajmuje pozycje dogodną dla strzelca wyborowego w sytuacji, w której posiada jedynie broń 
krótkodystansową. Podział na role w Firearms jest też dyktowany większą różnorodnością 
rozgrywki z uwagi na inne realia gry. 

Podobnie jak w Counter-Strike, w grze Firearms gracz przed rozpoczęciem rozgrywki może 
wybrać swój ekwipunek i dodatkowe umiejętności, jednak w tym przypadku jest znacznie 
więcej możliwości wyboru. Rozwiązaniem służącym do podejmowania wyboru przez bota 
są gotowe konfiguracje ekwipunku i zdolności. Programiści botów MarineBot stworzyli 
ponad 300 tego typu konfiguracji. W przypadku możliwości definiowania takich klas dla 


poszczególnej mapy, mógłby to również być mechanizm dostosowywania sposobu prowadzenia 
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rozgrywki przez boty do danej planszy. Niestety tak nie jest, bo modyfikacja tej konfiguracji 


wymaga rekompilacji kodu źródłowego botów MarineBot. 


3.4. Podsumowanie 


W rozdziale przedstawiono cztery boty grające w modyfikacje gry Half-Life. Boty 
działające w innych grach FPS (np. Quake) mogą charakteryzować się inną interakcją ze 
środowiskiem gry. Dzięki prezentacji botów działających w podobnym środowisku nie trzeba 
było opisywać tego środowiska w każdym przypadku osobno. 

Każdy z przedstawionych botów reprezentował inny typ gry, dla której został wykonany. 
Zostały omówione: 

— boty przeznaczone dla gry w trybie jednoosobowym, 

— boty dla rozgrywek wieloosobowych typu deathmatch, 

— boty dla rozgrywek drużynowych opartych na walce w zamkniętych pomieszczeniach, 

— boty dla rozgrywek drużynowych opartych na symulacji pola walki. 

Pomimo różnic w przeznaczeniu botów, pokazano bardzo wiele podobieństw między nimi. W 
rozdziale omówiono również wybrane szczegóły techniczne implementacji tychże botów, aby 
naświetlić problemy jakie próbowali rozwiązywać twórcy botów i jakie mieli pomysły na ich 
rozwiązanie. Przedstawione boty są rozwijane przez społeczność gry jako darmowe projekty 
typu Open-Source, więc nie są porównywalne do komercyjnych botów ze względu na inny 
charakter pracy zespołu projektowego [29]. 

Implementacja niemal każdego z botów wykorzystuje pewną formę punktów 
nawigacyjnych do wspomagania poruszania się botów po mapie. W ogólności punkty 
nawigacyjne stanowią mechanizm dostosowania zachowania botów do planszy. Zawierają 
one różnego rodzaju dodatkowe dane, dzięki czemu projektanci plansz mogą mieć wpływ na 
działanie botów na planszy. 

W większości z zaprezentowanych botów wykorzystany jest podział na akcje proste i 
złożone. Modele decyzyjne botów operują na akcjach złożonych. W oparciu o sygnały 
docierające ze środowiska gry i stan wewnętrzny bota wybierana jest akcja złożona, którą bot 
następnie wykonuje. 

Reguły zachowania botów zaprezentowanych w tym rozdziale zostały stworzone przez 
ich programistów i zapisane jako instrukcje języka programowania. Według Larsa Lindena 
[34] jest to najpowszechniejszy sposób tworzenia algorytmów sterowania zachowaniem botów, 
ze względu na możliwość wygodnego modyfikowania jego działania w trakcie prac nad grą 
komputerową. 

W omówionych botach stosowane są modele decyzyjne wykorzystujące reguły lub drzewa 


decyzyjne. W tych botach stosuje się również podejścia oparte na przypisywaniu akcjom 
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poziomu motywacji do ich wykonania. Niejednokrotnie też wyżej wymienione implementacje 
są wspierane automatami skończonymi, np. w każdym stanie jest rozpatrywane inne drzewo 
lub jego część. 

W większości z zaprezentowanych botów można wyróżnić wnioskowanie deliberatywne 
i reaktywne. Wnioskowanie deliberatywne polega na przeprowadzaniu analizy danych 
zebranych przez bota i podejmowania decyzji w oparciu o jej wynik. Natomiast wnioskowanie 
reaktywne polega na szybkim podejmowaniu decyzji w odpowiedzi na zdarzenia zachodzące w 
Świecie gry, najczęściej w celu zlikwidowania doraźnych problemów, po czym bot powraca do 
realizacji swoich celów. 

Analiza kodu źródłowego botów stanowiła punkt wyjścia do zdefiniowania autorskiego 
algorytmu sterowania botami o nazwie «Bot przedstawionego w rozdziale 4. Koncepcja 
działania botów kBot formalizuje użycie akcji prostych oraz złożonych, percepcji oraz stanu 
wewnętrznego bota. Algorytm ten został zaimplementowany w sposób opisany w rozdziale 5. 
Wybrane techniki implementacji inspirowane działaniem innych botów to np. użycie punktów 


nawigacyjnych do reprezentacji wiedzy o topologii planszy, po której poruszają się boty. 


4. Model funkcjonowania botów w grze 


W rozdziale tym zostanie formalnie opisane działanie środowiska gry typu FPS oraz 
funkcjonowanie botów w tej grze jako agentów działających w pewnym środowisku. 
Oznaczenia i definicje zawarte w tym rozdziale zostaną wykorzystane do opisu algorytmu 
sterowania botami kBot wykonanego w ramach pracy nad rozprawą. Opis bazuje na koncepcji 
funkcjonowania agentów wg Wooldridge'a, której istotne elementy są zaprezentowane w 
podrozdziale 4.1. W kolejnych podrozdziałach zawarty jest autorski opis działania środowiska 


gry FPS jako środowiska agentowego oraz funkcjonowania botów kBot. 


4.1. Model funkcjonowania agentów wg Wooldridge' a 


Michael Wooldridge w książce „Introduction to Multiagent Systems” [66] dokonał 
systematyzacji pojęć stosowanych w dziedzinie systemów agentowych. Zaprezentowany 
w tej książce model funkcjonowania agenta jest oparty na koncepcji racjonalnego agenta 
zaprezentowanego przez Russela i Norviga [51]. Jednak koncepcja Russela i Norviga 


koncentruje się na inteligencji jednostki, a Wooldridge skupia się na współdziałaniu agentów. 


4.1.1. Środowiska 


Wooldridge rozważa działanie agentów w środowisku. Przywołuje klasyfikację Russela i 

Norviga [51, s. 46], którzy wyróżniają następujące cechy środowisk: 

— całkowicie obserwowalne / częściowo obserwowalne 
W środowiskach całkowicie obserwowalnych agent ma możliwość zdobycia dokładnych 
informacji, które w pełni opisują stan środowiska. W środowiskach częściowo 
obserwowalnych agent zdobywa informacje częściowe lub niepewne. 

— deterministyczne / niedeterministyczne 
W deterministycznych środowiskach wykonanie akcji ma tylko jeden, znany rezultat. W 
niedeterministycznych — wykonanie akcji może prowadzić do różnych rezultatów. 

— statyczne / dynamiczne 
Środowiska statyczne mogą zmieniać się jedynie w wyniku akcji wykonanych przez agenta 
— dopóki agent nie wykona akcji, stan środowiska pozostaje niezmieniony. W środowiskach 
dynamicznych stan środowiska może być zmieniany przez innych agentów działających w 


środowisku lub samoistnie przez samo Środowisko. 


81 


— dyskretne / ciagte 

Srodowisko jest dyskretne, jeżeli zbiór akcji możliwych do wykonania jest przeliczalny 

oraz liczba możliwych obserwacji stanów środowiska jest przeliczalna. W ciągłych 

środowiskach możliwe jest zdefiniowanie pojęcia ciągłości na stanach środowiska i akcjach. 
— epizodyczne / czasu rzeczywistego! 

W środowiskach czasu rzeczywistego agent może podjąć decyzję w dowolnym momencie, 

środowiska epizodyczne nie mają tej własności — decyzje podejmowane są w pewnych 

ustalonych momentach. 

Wooldridge opisuje sytuację, w której pojedynczy agent działa w środowisku 
częściowo obserwowalnym, dyskretnym, statycznym, deterministycznym i epizodycznym. 
Zaprezentowany przez niego abstrakcyjny model środowiska jest skończonym zbiorem stanów: 
US Su Ues} 

Agent w środowisku ma do wyboru akcje ze zbioru A = {a,a’,...}, które 


deterministycznie zmieniają stan środowiska: 


a:U>U 


4.1.2. Agent bez stanu 


Rozważane jest środowisko częściowo obserwowalne, tj. agent może otrzymywać tylko 
fragmentaryczne informacje o stanie środowiska. Wooldridge do opisania tej cechy środowiska 
posługuje się pojęciem percepcji i obserwacji. Obserwacje służą do opisu stanu środowiska, a 
percepcja to proces pozyskiwania obserwacji. Zbiór możliwych obserwacji stanu środowiska 
jest oznaczany symbolem O. Percepcja agenta jest funkcją, która stanom środowiska przypisuje 


obserwacje. Funkcja ta jest oznaczana symbolem see, tj. 
see: U > O 


Decyzje o wyborze akcji są podejmowane przez agenta w oparciu o bieżącą obserwację 


środowiska. Funkcja decide wyraża decydowanie o wyborze akcji: 
decide : 0 > A 


W środowisku scharakteryzowanym przez zbiory U, A, O agent jest zdefiniowany jako 


krotka (see, decide) składająca się z dwóch wyżej wymienionych funkcji. 


' ten podział został wprowadzony przez Russela później. 
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Rysunek 4.1. Schemat omawianej interakcji agenta ze stanem i środowiska zaproponowanego przez 
Wooldridge’a 


4.1.3. Agent ze stanem 


Wooldridge proponuje rozszerzenie definicji agenta o stan wewnętrzny. W tym celu 











definiuje zbiór możliwych stanów I, które mogą być przyjęte przez agenta. Wprowadzona 





zostaje funkcja next opisująca zmiany stanu wewnętrznego na podstawie obserwacji 




















next: I x O73 








Funkcja wyboru akcji (decide) dla agenta ze stanem wewnętrznym przypisuje stanowi 


wewnetrznemu akcję, którą podejmuje w środowisku agent 











decide: I — A 





Agent ze stanem jest krotką (next, see, decide}. Schemat współdziałania zaprezentowanych 
funkcji znajduje się na diagramie 4.1. 

W innych częściach swojej pracy Wooldridge omawia aspekty działania agentów takie 
jak reprezentacja wiedzy, współpraca czy też ustalanie przez agentów celów do wykonania. 
Wprowadzony opis formalny nie jest jednak rozwijany, lecz w tekście można znaleźć 
komentarze wyjaśniające jak można opis ten rozbudować, aby uwzględniał opisywane przez 
autora zagadnienia. W rozprawie niektóre z tych aspektów funkcjonowania agentów zostaną 


uwzględnione w opisie działania botów. 


4.2. Adaptacja modelu Wooldridge’a do opisu funkcjonowania agentów w 
grze FPS 


Boty są agentami działającymi w środowisku gry komputerowej. Model funkcjonowania 


botów «Bot w środowisku gry Counter-Strike jest adaptacją modelu zdefiniowanego przez 
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Wooldridge’a. Dlatego przed zaprezentowaniem opisu działania botów «Bot zostanie 
przedstawione funkcjonowanie środowiska gry FPS i agentów w nim działających. 
Prezentowany model działania środowiska i agentów uwzględnia obserwacje poczynione 
podczas przeglądu sposobu implementacji botów, przedstawionych w rozdziale 3. Obserwacje 
te dotyczą charakteru interakcji między botami a środowiskiem gry, zastosowania podziału na 


akcje proste i złożone oraz wyodrębnienia percepcji botów. 


4.2.1. Środowisko gry 


Z punktu widzenia systemów agentowych, środowiskiem działania agentów, będących 
postaciami w grze komputerowej, jest plansza w tej grze. Postacie uczestniczące w grze, 
niezależnie czy są botami, czy też są sterowane przez gracza, są agentami w nomenklaturze 
systemów agentowych. 

Stan środowiska gry może zmieniać się niezależnie od działań postaci, np. drzwi 
otwarte przez postać zamykają się po pewnym czasie. Takie zachowanie można przedstawić 
poprzez wprowadzanie dodatkowych agentów, z właściwymi sobie akcjami, modelujących 
wybrane aspekty działania planszy. Celem tego rozdziału jest prezentacja działania botów 
uczestniczących w rozgrywce. Dlatego w celu uproszczenia opisu zakładamy, że stan planszy 
zmienia się jedynie pod wpływem akcji podejmowanych przez postacie w grze. 

Środowisko działania botów jest środowiskiem wirtualnym, czyli takim, które nie posiada 
fizycznej reprezentacji. Gracz obserwuje jego stan dzięki wizualizacji tworzonej przez 
komputer. 

Środowisko gry FPS jest postrzegane przez graczy jako środowisko czasu rzeczywistego, 
tzn. w każdym ograniczonym przedziale czasowym istnieje nieskończenie wiele momentów w 
czasie, w których gracz może podjąć decyzje i możliwe jest równoległe podejmowanie decyzji 
przez graczy. 

Przeciwieństwem gier czasu rzeczywistego są tzw. gry turowe. Takie gry charakteryzują 
się epizodycznym Środowiskiem gry. Wyróżnione są w nim momenty, nazywane turami, 
w których gracze naprzemiennie podejmują decyzje (np. szachy). W rzeczywistości 
środowiska dowolnych gier komputerowych czasu rzeczywistego są realizowane technicznie 
jako środowiska epizodyczne, w których dodatkowo wprowadzono limit czasu t; na podjęcie 
decyzji. Limit t, jest stały i niezależny od gracza. Niepodjęcie decyzji w limicie czasowym 
oznacza „brak decyzji” — co jest, według zasad gry, poprawną decyzją. Taka decyzja zazwyczaj 
nie ma żadnego wpływu na środowisko gry. Przy odpowiednio małej wartości t; człowiek nie 
jest w stanie odróżnić środowiska epizodycznego od środowiska czasu rzeczywistego z powodu 
ograniczeń zdolności poznawczych. 

Boty grające w gry w środowiskach epizodycznych często wykorzystują drzewa gry 


[2] w celu podejmowania decyzji. Jednakże w przypadku środowisk czasu rzeczywistego, 
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bezpośrednie zastosowanie takiego rozwiązania jest niemożliwe ze względu na konieczność 
rozpatrywania liczby decyzji, która przewyższa możliwości obliczeniowe dostępne dla 
algorytmu sterującego botem. 


W tej pracy będzie rozpatrywane środowisko epizodyczne, w którym agenci kolejno 











wykonują akcje ze zbioru A. Zbiór agentów (ozn. B) jest z góry ustalony i zawiera skończoną 





liczbę elementów, n = card (B). 
Niemal w każdej grze FPS akcjami mogą być przemieszczanie się i używanie broni. 
W przypadku gry Counter-Strike, rzadziej stosowane, aczkolwiek równie istotne, są akcje 
kupowania broni, interakcja z zakładnikami, podkładanie bomb, etc. W przypadku bardziej 
rozbudowanych gier FPS, możliwych interakcji pomiędzy uczestnikami rozgrywki może być 
więcej, mogą być to np. dialogi lub handel. Takie interakcje występują np. w grach FPS z 
elementami RPG takich jak gry z serii Fallout czy też Deus Ex. 
Nawiązując do klasyfikacji Wooldridge'a (zobacz rozdział 4.1.1), środowisko gry FPS 
będzie scharakteryzowane w sposób następujący: 
— częściowo obserwowalne — uzyskanie pełnych informacji o jego stanie jest niemożliwe 
(patrz dalej 4.2.2); 
— deterministyczne — podjęcie każdej akcji prowadzi do z góry znanego rezultatu; 
— dynamiczne — środowisko zmienia się nie tylko w wyniku akcji wykonanych przez 
działającego w nim agenta, ponieważ w środowisku działa wielu agentów; 
— dyskretne — w jednostce czasu agent podejmuje dokładnie jedną akcję; 
— epizodyczne — agenci podejmują decyzje w Ściśle określonych momentach w czasie. 
Środowisko gry ma pewien właściwy sobie stan. Stan środowiska gry zmienia się w każdej 
turze gry na skutek decyzji kolejno podejmowanych przez działających w nim agentów. Bot 
wybiera akcje do wykonania ze zbioru A = {a,a’,...}. Akcje zmieniają stan środowiska 


inaczej w zależności wykonującego je agenta: 











a:BxU-U 





Jest to proste uogólnienie sposobu zmiany stanu środowiska podanej przez Wooldridge’a na 


przypadek, w którym w środowisku działa wielu agentów. 


4.2.2. Percepcja bota w środowisku gry komputerowej 


Gracz odbiera informacje o stanie środowiska gry w formie graficznej tworzonej przez 
komputer. Jest to wizualizacja 3D informacji przestrzennych planszy oraz dane o postaci 
sterowanej przez gracza w formie HUD?[14]. W tak stworzonej wizualizacji gracz odczytuje 


częściowe informacje o środowisku gry. 


2 ang. Head-up Display - wyświetlacz przezierny prezentujący informacje bez zasłaniania wzroku. 
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Bot odczytuje stan środowiska gry bezpośrednio z pamięci komputera i może mieć dostęp 
do pełnych informacji o Świecie gry. Jednakże bot swoim zachowaniem powinien naśladować 
gracza, więc powinien zachowywać się tak jakby odbierał częściowe informacje o świecie gry, 
np. żeby gracze mogli się chować przed botem. 

Nawiązując do Wooldridge a percepcja u bota jest funkcją przypisującą stanowi środowiska 
jej obserwację. Ponieważ rozważane jest środowisko, w którym działa wielu agentów funkcja 


ta przyjmuje identyfikator agenta. 
see : B x U => O 


Obserwacja może być na przykład wartościowaniem zmiennych opisujących postać 


sterowaną przez bota. 


4.3. Opis funkcjonowania bota «Bot 


4.3.1. Decyzje wysokopoziomowe 


W przypadku botów «Bot zastosowane są akcje złożone (patrz rozdział 2) w celu organizacji 
akcji prostych (A) w struktury, które mogą być w łatwy sposób wykorzystywane przez 
programistę do opisania działania bota za pomocą kodu. Przykłady zastosowań akcji złożonych 
są widoczne w implementacjach botów, omówionych w rozdziale 3, oraz w przeglądzie 
literatury, poświęconej planowaniu zachowań botów (rozdział 2). 

W algorytmie sterującym zachowaniem botów «Bot można wyróżnić funkcję 
podejmowania decyzji wysokopoziomowych. Decyzja wysokopoziomowa składa się z 
akcji złożonej oraz jej celu, motywacji i kontynuacji. Zbiór decyzji wysokopoziomowych jest 


oznaczany jako © i jest zdefiniowany jako: 


D= A x Gx M x pD UL) (4.1) 
we NZ O YY 


akcje cele motywacje kontynuacje 
złożone 


Definicja zbioru © jest rekurencyjna, ponieważ kontynuacja jest decyzją 
wysokopoziomową. Bot podejmuje tylko skończone decyzje wysokopoziomowe, dlatego 
wprowadzona jest pusta decyzja wysokopoziomowa, oznaczona |. Pusta decyzja zawsze 


występuje w decyzji wysokopoziomowej na pewnym poziomie zagnieżdżenia. 


86 


Element ze zbioru © jest krotka. Operatory rzutowania na każdą z współrzędnych w tej 


krotce będą zdefiniowane jako 


action: D > 4 (akcja złożona) 
goal: D > G (cel) 
motivation: D > M (motywacja) 


cont: © — D (kontynuacja) 


Każdy z tych elementów zostanie omówiony poniżej. 

Cel decyzji wysokopoziomowej 

Cel jest sposobem parametryzowania akcji złożonej np. akcja „idź do” wymaga parametru 
w identyfikatora punktu nawigacyjnego. Cel dla decyzji ruchu do pewnego miejsca na planszy 
można określić jako zbiór takich staaów wewnętrznych agenta, dla których możliwe jest 
stwierdzenie, że agent znajduje się w danym miejscu. 

Racją bytu każdej akcji złożonej jest doprowadzenie agenta do pewnego pożądanego stanu 
wewnętrznego. Z tego powodu cel decyzji jest wyrażony jako zbiór pożądanych stanów 


wewnętrznych agenta. Zbiór ten będzie oznaczany jako G 
G c2! (4.2) 


Dla każdego elementu g € G zachodzi 














ge (4.3) 











Jeżeli bieżący stan agenta 4 € I zawiera się w zbiorze g € G będącym celem akcji, to oznacza 





zakończenie jej sukcesem. 
Akcja złożona 
Bot dokonuje wyboru akcji złożonej ze skończonego zbioru akcji możliwych do wyboru”. 


Akcja złożona jest modelowana przez funkcję: 











xG>A 





Jej parametrami są stan wewnętrzny agenta oraz cel akcji. Zbiór tych funkcji jest oznaczany 
jako 2. 











ac [I xG>A] (4.4) 





3 Przykładowo boty E[POD] mogą wybierać spośród 16 akcji tego typu. 
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Zbiór akcji złożonych jest skończony, ponieważ programista botów posługuje się skończoną 
liczbą akcji w celu zaprogramowania działania bota. Jest to założenie metodyki prezentowanej 
w rozprawie poparte spostrzeżeniami przedstawionymi w rozdziale 3. 

Motywacja akcji złożonej 

Inspiracja do wykorzystania motywacji płynie z architektury BDI*[53]. W przypadku 
botów kBot programista za pomocą motywacji może wyspecyfikować warunki, jakie muszą 
być spełnione, aby wykonanie związanej z nią akcji złożonej było kontynuowane. Mechanizm 
motywacji pozwala na wcześniejsze przerwanie akcji złożonej, niezależnie od osiągnięcia jej 
celu. Inaczej jednak niż w przypadku celu, motywacja nie jest parametrem akcji złożonej. 
Wybór motywacji nie ma wpływu na decyzje niskopoziomowe podejmowane w ramach akcji 
złożonej. 

Podobnie jak cel motywacja jest opisywana jako zbiór stanów wewnętrznych bota, a zatem 
przestrzeń motywacji jest zbiorem 

M Cc 2" 


a dla każdego elementu m e M zachodzi: 











m c 





Motywacja m € M specyfikuje warunki, w jakich wykonanie zadania powinno być 


podtrzymane. Podobnie jak w przypadku celu, motywacja m jest spełniona dla stanów agenta 




















i € I dla których zachodzi 7 € m. Przykładowo, jeżeli m = I, to zadanie będzie wykonywane 








w dowolnych warunkach. 

Kontynuacja decyzji wysokopoziomowej 

Ostatnim ważnym czynnikiem tworzącym decyzję wysokopoziomową w rozważanym 
modelu jest kontynuacja. Jest to element, który pozwala składać decyzje wysokopoziomowe 
w sekwencje 1 umożliwia proste planowanie oraz organizowanie decyzji wysokopoziomowych 
w struktury wyższego rzędu. 

W przypadku zakończenia decyzji sukcesem poprzez osiągnięcie związanego z nią celu, bot 
realizuje decyzję wysokopoziomową będącą kontynuacją zakończonej decyzji. Kontynuacja 


może być stworzona z istniejącej decyzji poprzez zastosowanie operatora rozszerzania 


4 ang. Beliefs, Desires, Intentions - architektura agentowa, w której do opisu zachowania agentów 
g g J p g 
wykorzystuje się pojęcia takie jak przekonania, pragnienia i intencje. 
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kontynuacji. Jest on zdefiniowany w następujący sposób: 





|:|DxD>9 
dy „jezeli d = L 
dı || da = 4 dy „jeżeli dy = L 
(a,g,m,c || dz) ja gm.e) 


Rozszerzanie kontynuacji decyzji jest używane w przypadku wnioskowania reaktywnego. 
Bot podejmuje pewną decyzję wysokopoziomową dı w odpowiedzi na nieprzewidzianą 
sytuację w środowisku gry i łączy ją z dotychczasową decyzją d za pomocą wyżej 


wymienionego operatora, tj. wynikiem wnioskowania reaktywnego jest d; ||d>. 


4.3.2. Wnioskowanie bota 


Procesy wnioskowania bota są mechanizmami tworzenia nowych decyzji 
wysokopoziomowych. Programista poprzez określenie działania procesów wnioskowania 
definiuje działanie botów kBot. W przypadku bota kBot wyróżnia się dwa typu wnioskowania: 
deliberatywne i reaktywne. 

Pojęcia wnioskowania deliberatywnego i reaktywnego są głęboko zakorzenione w 
dziedzinie systemów agentowych. Intuicyjnie, wnioskowanie deliberatywne oznacza 
analizowanie sytuacji. Jest ono potencjalnie czasochłonne. Natomiast wnioskowanie reaktywne 
jest prostsze, za to przeprowadzane częściej, w celu reagowania na zmiany w środowisku 
agenta. Konkretne rozumienie tych pojęć zależy jednak od przeznaczenia systemu. Tutaj 
zostanie przedstawione jak są one rozumiane w przypadku botów «Bot. 

Wnioskowanie deliberatywne jest procesem decyzyjnym, w którym analizowana jest 
sytuacja taktyczna oraz przewidywane są ruchy przeciwnika. Proces ten jest kosztowny 


obliczeniowo, więc jest przeprowadzany periodycznie. Jest on reprezentowany jako funkcja: 
ra. DxXxIAD 
Ten typ wnioskowania zawsze powoduje podjęcie pewnej decyzji wysokopoziomowej, tj. 
Vietaep Ta(d,i) A L 


Natomiast wnioskowanie reaktywne jest procesem decyzyjnym, służącym do odpowiadania 
na wystąpienie nagłych, niespodziewanych zdarzeń w Świecie gry. Jest to zestaw 
łatwych do obliczenia reguł, które prowadzą do podjęcia decyzji, będącej odpowiedzią na 


obserwację zachodzącego zdarzenia. Podobnie jak wnioskowanie deliberatywne proces ten jest 
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reprezentowany jako funkcja: 





Tri DxIwAD 











W obu typach wnioskowania, wynik jest decyzją wysokopoziomowa, zależną od bieżącej 














decyzji wysokopoziomowej © oraz od stanu wewnętrznego agenta I (rozdz. 4.3.3). 


4.3.3. Stan wewnętrzny bota 


Podobnie jak w przypadku agentów Wooldridge’a rozpatrywany jest agent ze stanem 1 
funkcją zmiany stanu next. 

Bot pamięta aktualnie realizowaną decyzję wysokopoziomową. W sposób analogiczny 
do definicji funkcji next można wprowadzić funkcję next, opisującą zmiany decyzji 


wysokopoziomowych wybranych do realizacji przez agenta. 











nexta: O9 xI> D 





Wynik działania funkcji nextą zależy od bieżącej decyzji wysokopoziomowej oraz stanu 
wewnętrznego agenta. Wynikiem działania tej funkcji może być podtrzymanie wybranej 
decyzji lub jej zmiana. 

Biorąc pod uwagę przedstawione wcześniej elementy decyzji wysokopoziomowych: cele, 
motywacje i kontynuacje, oraz wnioskowanie, można opisać w jaki sposób funkcja nexty 
wpływa na wybraną przez bota decyzję wysokopoziomową. 

Jeżeli wnioskowanie reaktywne prowadzi do powstania nowej decyzji wysokopoziomowej, 
to nowa decyzja powstaje poprzez złożenie decyzji powstałej w wyniku działania wnioskowania 
reaktywnego i bieżącej decyzji za pomocą operatora II. 

W przypadku osiągnięcia celu decyzji wysokopoziomowej wybierana jest kontynuacja 
tej decyzji, o ile istnieje, a w przeciwnym przypadku nowa decyzja wysokopoziomowa jest 
wybierana przez wnioskowanie deliberatywne. 

W przypadku niespełnienia motywacji decyzji wysokopoziomowej, bieżąca decyzja jest 
zastępowana przez wynik działania wnioskowania deliberatywnego. 


Powyższe zasady można przedstawić jako definicję funkcji nexty. Dla dowolnego stanu 














i € I i decyzji wysokopoziomowej d € D zachodzi 








rr(d,i)||d jeżeli r,(d,i) A L 
cont(d) jeżeli r,(d,i) = L A i€ goal(d) A cont(d) £ L 
next, (d,i) = 4 ra(d, i) jeżeli r,(d,i) = L A i € goal(d) A cont(d) = L (4.5) 
ra(d, i) jeżeli r,(d,i) = L A ig£ goal(d) Ai £ motivation(d) 
d , Wpp 
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Schemat interakcji wszystkich elementów tworzących boty «Bot jest przedstawiony na 


rysunku 4.2. 















































de®D "= 

„QD = -------- > decision -- 
| d€D 'd€9 

p ae „GEL 

0€O me % 
r- ------ ' esos + decide ---. 
+ Te [M i 
next ----> state i 

uEU: iE l aEA 

"8; Środowisko a 


Rysunek 4.2. Schemat omawianej interakcji botów «Bot i Środowiska gry. 


4.3.4. Przykłady działania procesu decyzyjnego 


W celu lepszego zobrazowania współdziałania elementów architektury botów «Bot, 
przedstawiono przykład robota, którego zadaniem jest sprzątanie dwóch pokoi w mieszkaniu. 
Robot ma do dyspozycji następujące akcje złożone: 

— Clear — akcja polegająca na sprzątaniu pomieszczenia, 
— ChargeBattery —akcja polegająca na znalezieniu gniazdka elektrycznego i naładowaniu 
baterii, 


— NextRoom — akcja polegająca na zmianie pomieszczenia, w którym robot się znajduje, 





— Idle -akcja polegająca na nie wykonywaniu żadnych czynności przez robota. 
Przestrzeń obserwacji jest definiowana za pomocą zmiennych logicznych opisujących 
następujące sytuacje: 
— room_1_clean — pokój nr 1 jest czysty, 
— room_2_clean — pokój nr 2 jest czysty, 
— in_room_1 = robot znajduje się w pokoju nr 1, 
— in_room_2 — robot znajduje się w pokoju nr 2, 


— battery_low — bateria robota jest prawie rozładowana. 
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Zbiór wyżej wymienionych zmiennych będzie oznaczany jako V. Zbiór możliwych 


obserwacji to zbiór wartościowań zmiennych V. 
O = {0,1}" 


Rozpatrywane środowisko spełnia założenie o zamkniętym Świecie — każda zmienna 
posiada przypisaną wartość logiczną przez wartościowanie będące obserwacją. 
Robot przebywa w dokładnie jednym pokoju w danym momencie, z tego powodu zbiór 


obserwacji środowiska spełnia warunek 


Voco o(in_room_1)=1 V o(in_room_2) = 1 


Voco —|o(in_room_1) = o(in_room_2) | 


Stan wewnętrzny agenta jest zawiera jedynie ostatnią obserwację środowiska przez agenta, 


tj. 











=O 





Celem akcji NextRoom jest zmiana pokoju, w którym znajduje się robot. Można 
wyróżnić ruch do pokoju nr | i pokoju nr 2. Robot używa dwóch celów dla tej decyzji 


wysokopoziomowej. 





Gn, = {i € 1: (in_room_1) = 1} 

















gn, = {i E I: i(in_room 2) = 1} 


W przypadku akcji sprzątania pokoju, Clear, robot używa również 2 różnych celów 








Ja = {i El: i(room_1 _cl ean) = 1} N gni 














Jeo = {i El: i(room_2_cl ean) = 1} N gna 





Cel akcji ładowania baterii, ChargeBattery, jest tylko jeden — naładowanie baterii. 











9% = {i € 1: i(battery_low) = 0} 





Zadaniem robota jest przemieszczanie się pomiędzy pomieszczeniami i sprzątanie ich. W 


razie potrzeby konieczne może być naładowanie baterii. 


Przykład 1: Wnioskowanie deliberatywne i reaktywne 
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Funkcje podejmowania decyzji wysokopoziomowych (ry i r,) przez robota można wyrazić 



















































































następująco: 
OE E, Seal i(room_1_clean) = 0 
A i(in_room_1) = 1 
i(room_1_clean) = 1 
(NextRoom, gn,, I, L) „jeżeli A i(room_2_clean) = 0 
A i(in_room_1) = 1 
ra(d,i)=4 (Cleax,gel l) „jeżeli MtoomPclean) = 0 
A i(in_room_2) = 1 
i(room_1_clean) = 0 
(NextRoom, gn,, I, L) „jeżeli A i(room_2_clean) = 1 
A i(in_room_2) = 1 
(Idle L) EN i(room_1_clean) = 1 
a A i(room_2_clean) = 1 
(ChargeBattery, gy, 1, L) , jeżeli BAZE =l 
r,(d, i) = A action(d) # ChargeBattery 
L w.p.p 


W przedstawionym przykładzie proces ładowania baterii jest traktowany jako sytuacja 
wyjątkowa w stosunku do normalnego funkcjonowania robota jakim jest przemieszczanie 
się i sprzątanie. Decyzja o ładowaniu baterii jest podejmowana za pomocą wnioskowania 
reaktywnego. Warunkiem podjęcia decyzji o ładowaniu baterii jest zaobserwowanie stanu, w 
którym bateria jest rozładowana (i(battery_low) = 1) i niewykonywanie akcji ładownia baterii 
(action(d) 4 ChargeBattery). 

W przykładzie zostały podane 4 reguły wnioskowania deliberatynego. Dwie dotyczą pokoju 
nr 1 i dwie pokoju nr 2. 

Jeżeli robot znajduje się w pokoju nr 1 (i(in_room_1) = 1) i pokój ten nie jest posprzątany 
(i(room_1_clean) = 0) to robot podejmie decyzje o sprzątaniu tego pokoju. Jest to wyrażone 
jako decyzja wysokopoziomowa, gdzie akcją złożoną Clear a celem jest sprzątanie pokoju nr 
1 (ge). 

Jeżeli robot znajduje się w pokoju nr 1 (i(in_room_1) = 1) i pokój ten jest posprzątany 
(i(room_1_clean) = 1) a pokój nr 2 nie (i(room_2_clean) = 0) to robot podejmie decyzje o 
przemieszczeniu się do sąsiedniego pokoju. Jest to wyrażone jako decyzja wysokopoziomowa, 


gdzie akcją złożoną NextRoom a celem jest przemieszczenie robota do pokoju nr 2 (gn,). 
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Podobne reguły są zdefiniowane dla pokoju nr 2. Jeżeli robot się w nim znajduje i pokój 
wymaga sprzątania to go sprząta, w przeciwnym przypadku przemieszcza się do pokoju nr 1, 
gdy nie jest on posprzątany. 

W przypadku, gdy posprzątane są oba pokoje (i(in_room_1) = i(in_room_2) = 1) robot 





czeka bezczynnie wykonując akcję Idle. 


Każda z decyzji w przykładzie zawiera motywację składającą się z całego zbioru stanów 











robota I. Oznacza to, że robot nie będzie przerywał wykonania akcji z powodu niespełniania 





motywacji. W tym przykładzie wykorzystanie motywacji nie jest konieczne. 














Przykład 2: Wyłącznie wnioskowanie deliberatywne 
Zachowanie robota można wyrazić posługując się wyłącznie wnioskowaniem 
deliberatywnym (ra). Funkcja podejmowania decyzji wysokopoziomowych są zdefiniowane w 


następujący sposób: 











Moat = {i € 1: i(battery_low) = 0} 





i(in_room_l) = 1 
(Clear, ge, , MBat, L) „jeżeli A i(room_1_clean) = 0 


A i(battery_low) = 0 


i(in_room_1)=1 
(NextRoom, Jna; M Bat, 1) > jeżeli A i(room_1_clean) =1 
N i(room_2_clean) = 0 


A i(battery_low) = 0 


i(in_room_2) = 1 
(Clear, ge, MBat, L) „jeżeli A i(room_2_clean) = 0 


ra(d,i) = A i(battery_low) = 0 


i(in_room_2) = 1 
(NextRoom, dn, , M Bat, L) > jeżeli A i(room_1_clean) =0 
A^ i(room_2_clean) = 1 


A i(battery_low) = 0 
i(room_1_clean) = 1 
, MBat, L) „ jeżeli A i(room_2_clean) = 1 


A i(battery_low) = 0 











(Idle 

















(ChargeBattery,g,l, L) , jeżeli i(battery_low) = 1 





r, (d,i) = L 
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W przykładzie powyżej zachowanie robota jest wyrażone wyłącznie za pomocą 
wnioskowania deliberatywnego. Wnioskowanie to jest przeprowadzane w przypadku, gdy 
robot zakończył wykonywanie akcji złożonej i ewentualnych kontynuacji. W czasie wykonania 
akcji złożonej przez robota jego bateria może ulec rozładowaniu. Dlatego robot musi przerwać 
wykonanie bieżącej akcji i naładować baterie. Z tego powodu decyzje nie będące ładowaniem 
baterii mają przypisaną motywację, która jest niespełniona w przypadku stanu, w którym bateria 
jest rozładowana (mat). Decyzja o ładowaniu baterii ma przypisaną motywację złożoną ze 
wszystkich stanów agenta. Oznacza to, że wykonanie tej akcji nie będzie przerywane z powodu 
niespełnienia motywacji. 

Reguły sprzątania pokoi i przemieszczania się między nimi różnią się od tych z 
poprzedniego przykładu dodatkowym warunkiem, który polega na sprawdzeniu czy bateria 
nie jest rozładowana (i(battery_low = 0). Warunek tej został dodany po to, żeby robot 
podejmował decyzje o ładowaniu baterii w sytuacji, gdy bateria jest rozładowana. W 
sytuacji, gdy bateria jest rozładowana bieżąca akcja zostanie przerwana z powodu niespełnienia 
motywacji i zostanie wybrana decyzja o ładowaniu baterii. 

Jedyną przesłanką do podjęcia decyzji o ładowaniu baterii jest stwierdzenie faktu, że bateria 
jest rozładowana. Nie ma warunku, takiego jak w poprzednim przykładzie, polegającego na 
sprawdzeniu bieżącej akcji. Warunek ten nie jest potrzebny, bo wnioskowanie deliberatywne 
jest przeprowadzane tylko w ściśle określonych momentach, a nie w każdym epizodzie 


działania robota, jak wnioskowanie reaktywne. 














Przykład 3: Wyłącznie wnioskowanie reaktywne 
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W przypadku wykorzystania wnioskowania reaktywnego do kontrolowania robota reguty 


funkcja r, przyjmuje następującą postać: 











ra(d,i) = (Tale, I, Ø, L) 








i(in_room_1) = 1 





A^ i(room_1_clean) = 0 
A i(battery_low) = 0 
A action(d) Æ Clear 








— 


(Cl ear, Je; , jeżeli 





i(room_1_clean) = 1 

A^ i(room_2_clean) = 0 
„jeżeli A i(in_room_1) = 1 

A i(battery_low) = 0 

A action(d) Æ NextRoom 














— 


(NextRoom, gn, 


i(in_room_2) = 1 
r (d,i) = TE AE Jaa N i(room_2_clean) = 0 
A i(battery_low) = 0 


A action(d) Æ Clear 














i(room_1_clean) = 0 

A i(room_2_clean) = 1 
„jeżeli A i(in_room_2) = 1 

A i(battery_low) = 0 

A action(d) Æ NextRoom 











— 


(NextRoom, gn,, 





i(battery_low) = 1 
A action(d) 4 ChargeBattery 











(ChargeBattery, gy, 1, L) , jeżeli 





SE w.p.p 


Zachowanie robota jest wyrażone za pomocą wnioskowania reaktywnego. Jest ono 
przeprowadzane w każdej chwili, w której robot może podjąć decyzję. Z tego względu 
motywację nie są użyte w przykładzie. Warunki reguł są bardziej skomplikowane niż w 
dwóch poprzednich przykładach. Każdy warunek zawiera sprawdzenie bieżąco wykonywanej 
akcji - jest on konieczny ze względu na specyfikę wnioskowania reaktywnego. Jest ono 
przeprowadzane w każdym epizodzie decyzyjnym robota, a decyzje podejmowane na drodze 
tego wnioskowania łączone są za pomocą kontynuacji. Brak sprawdzenia tego warunku 
powodowałoby stworzenie wielu niepotrzebnych kontynuacji dla decyzji wybranej przez 


robota. 





Przeprowadzenie wnioskowania deliberatywnego powoduje podjęcie decyzji Idle, której 


cel jest zawsze spełniony. Decyzja ta nie ma żadnego wpływu na środowisko działania robota. 
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Ukończywszy swoje zadania robot oczekuje w tym stanie na zmianę wartościowania zmiennych 


room_1_clean lub room_2_clean. 














Przykład 4: Wnioskowanie z kontynuacjami 





i(in_room_1) = 1 








— 


(Clear, ga, , jeżeli 





A i(room_1_clean) = 0 


i(in_room_1) = 1 
(NextRoom, gna; I, (Clear, ge, I, L)) „jeżeli A i(room_1_clean) = 1 


A i(room_2_clean) = 0 


























i(in_room_2) = 1 











ra(d, i) = 4 (Clear, g,,,1, | , jeżeli 
ŚR l ) A^ i(room_2_clean) = 0 


ilin_room_2) = 1 
(NextRoom, gn,,1, (Clear, ges, I, L)) „jeżeli A i(room_1_clean) = 0 


A^ ifroom_2_clean) = 1 























i(room_1_clean) = 1 























(Idle,I,I, L) , jeżeli 
A i(room_2_clean) = 1 





|... i(battery_low) = 1 
(ChargeBattery,gy,l, 1) „jeżeli “Petterytow) 


Tad i) = A action(d) Æ ChargeBattery 











L w.p.p 


Wnioskowanie zaprezentowane w tym przykładzie jest modyfikacją wnioskowania z 
przykładu 1, wykorzystującego wnioskowanie deliberatywane oraz reaktywne. Sytuacja 
ładowania baterii jest obsługiwana za pomocą wnioskowania reaktywnego. Wnioskowanie 
deiberatywne posiada pięć reguł. Dwie spośród nich odwołują się one do sekwencji decyzji 
skonstruowanej przy pomocy mechanizmu kontynuacji. 

Jeżeli robot znajduje się w pokoju wymagającym sprzątania to robot go sprząta. Jeżeli 
natomiast pokój jest posprzątany, a sprzątania wymaga sąsiedni pokój to robot wykorzystuje 
decyzję wysokopoziomową składającą się z akcji ruchu i sprzątania. Ta decyzja jest zbudowana 


za pomocą kontynuacji. 














Zaprezentowane 4 możliwe sposoby opisania algorytmu podejmowania decyzji wskazują 
na możliwość wzajemnego zastępowania mechanizmów wnioskowania reaktywnego i 
deliberatywnego. Robota można zaimplementować wykorzystując jeden lub oba z tych 


mechanizmów. Podział na te dwa typy wnioskowania został poczyniony celowo, ze względu na 
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możliwość zwiększenia wydajności działania bota oraz lepszej organizacji reguł podejmowania 
decyzji. Wnioskowanie deliberatywne jest uruchamiane w wybranych momentach i jest 
operacją kosztowną. Natomiast wnioskowanie reaktywne polega na prostym odpowiadaniu na 
zmiany środowiska, jest uruchamiane w każdej turze i musi być proste. 

Wykonanie akcji złożonej trwa wiele epizodów, w których robot może podjąć decyzję 
o zmianie wykonywanej akcji poprzez wnioskowanie reaktywne. Dlatego reguły użyte we 
wnioskowaniu reaktywnym odwołują się do stanu wewnętrznego robota w celu sprawdzenia 


czy robot już podjął działanie na zdarzenie, które jest wyzwalane przez to wnioskowanie. 


4.4. Komunikacja i współpraca agentów 


Pojęcia komunikacji i współpracy są ze sobą Ściśle powiązane w przypadku systemów 
agentowych, ponieważ komunikacja między agentami jest wykorzystywana w celu koordynacji 
współpracy. 

W grze Counter-Strike, 1 znacznej liczbie innych gier komputerowych typu FPS, 
komunikacja pomiędzy postaciami w grze jest uproszczona. Postacie w grze Counter-Strike 
symulują żołnierzy jednostki antyterrorystycznej oraz terrorystów. Zarówno jedni jak i drudzy 
podczas akcji nie toczą skomplikowanych dialogów z uwagi na niebezpieczne środowisko, 
w jakim działają. Polegają na uprzednim dobrym przygotowaniu, planowaniu i schematach 
postępowania. Istnieją też ograniczenia w sposobach komunikacji między graczami grającymi 
tę grę. Gra toczy się za pośrednictwem internetu i nie ma możliwości skutecznej komunikacji. 
Podczas gier turniejowych gracze co prawda znajdują się w jednym miejscu, ale tempo gry jest 
tak duże, że nie mają oni czasu na komunikowanie strategii drużyny. Polegają wtedy, podobnie 
jak żołnierze, których symulują ich postacie, na wcześniejszym przygotowaniu i planowaniu. 

W grze wiele zależy od przygotowania graczy i wykorzystywanych przez nich taktyk. 
Gracze w drużynie znają swoje taktyki i dzięki temu mogą planować działania zgodnie z 
wybraną taktyką. Podobne schematy postępowania mają miejsce w innych grach, gdzie 
możliwości skutecznej komunikacji są ograniczone, np. w piłce nożnej [55]. 

Teoria systemów agentowych Wooldridge’a dużą rolę przykłada do komunikacji i 
budowania współpracy pomiędzy agentami. Programowanie agentowe w Świetle tej teorii jest 
prezentowane jako paradygmat projektowania systemów, będący rozwinięciem programowania 
obiektowego. Zrozumiała i przejrzysta wymiana komunikatów pomiędzy agentami jest więc 
bardzo ważnym czynnikiem, gdyż agenci są implementowani przez różnych programistów. 
Boty w grze komputerowej są bytami mniej złożonymi systemy informatyczne tworzone 
w paradygmacie programowania agentowego, jednak zrozumiała komunikacja w przypadku 


botów kBot odgrywa ważną rolę, ponieważ zachowanie agentów może być zmieniane przez 
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różnych programistów, np. poprzez dostarczenie skryptu zawierającego reguły postępowania 
na nowej planszy w grze. 

Wooldridge wyróżnia następujące typy koordynacji współpracy: 

— przez globalne planowanie 

Agenci znają pojęcie planu. Jest on dzielony na części, które są wykonywane przez 

agentów samodzielnie wyznaczających cele 1 tworzących podplany. komunikacja zachodzi 

w przypadku kolizji planów i dzieleniu planu głównego. 

— przez prawa społeczne 

Członkowie drużyny zobligowani są do przestrzegania praw, które określają ich wzajemne 

interakcje, np. postępują według przygotowanego wcześniej schematu. 
— przez wspólne intencje 

Polega na komunikowaniu oczekiwań wobec zachowania innych i negocjowaniu sposobu 

postępowania agentów. 

— przez wzajemne modelowanie 

Każdy agent przewiduje zachowanie innych agentów w zespole i na tej podstawie podejmuje 

decyzje odnośnie własnego postępowania. 

Przykładem współpracy opartej na prawach społecznych jest działanie drużynowe 
opierające się na schematach postępowania, w których agenci mają z góry określone role i 
zadania. Przykładowo, współpraca poprzez prawa społeczne jest zastosowania przez boty 
MarineBot w grze Firearms (patrz rozdz. 3.3.4), w której definiuje się role członków 
drużyny. Bot, znając role innych członków drużyny, wie jakiego zachowania może od nich 
oczekiwać i może uwzględnić to przy podejmowaniu decyzji. Innym przykładem zastosowania 
praw społecznych jest wykorzystany w botach E/POD] podział drużyny na mniejsze zespoły. 
Każdy bot podejmuje decyzję o przynależności do drużyny i wybiera przywódcę na podstawie 
informacji znanych wszystkim agentom w drużynie. 

Środowisko gry Counter-Strike zapewnia dwa sposoby komunikacji: czat tekstowy i 
predefiniowane komunikaty radiowe. Boty kBot komunikując się wykorzystują akcje złożone 
w celu wysyłania komunikatów radiowych lub tekstowych do innych botów. Akcje te zmieniają 
stan środowiska gry, z którego inne boty za pomocą funkcji see odczytują informacje o 
wysłanym do nich komunikacie. Treści komunikatów wysyłanych przez boty oraz reakcje na 
nie zależą od implementacji funkcji rq oraz r,. Z tego powodu model funkcjonowania botów 
«Bot nie narzuca żadnej konkretnej formy współpracy. 

Agenci działają w środowisku, które jest symulacją i ich autonomia zależy w dużej mierze 
od założeń projektowych. Wymiana komunikatów między botami kBot może być realizowana 
za pomocą bezpośredniego przekazywania danych w pamięci komputera, z pominięciem 


symulowanego środowiska. 
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W grze często wykorzystywana jest komunikacja między graczami, które nie jest 
zapewniana przez środowisko gry, lecz przez zewnętrzne narzędzia. Jest to przede wszystkim 
komunikacja głosowa. Może być ona bezpośrednia, np. w sytuacji gdy gracze znajdują się 
fizycznie w jednym pomieszczeniu, lub za pośrednictwem techniki VoIP. 

Przy projektowaniu botów kBot podjęto decyzję o dopuszczeniu komunikacji, która pomija 
mechanizmy środowiska gry. Zachowano jednak umiar w wykorzystaniu tego sposobu 
komunikacji, aby nie doprowadzić do załamania autonomii agentów ani nie dawać im przewagi 


nad graczem, np. poprzez możliwość natychmiastowej wymiany informacji. 


4.5. Podsumowanie 


W tym rozdziale opisano w sposób formalny funkcjonowanie środowiska gry oraz botów 
kBot, będących przedmiotem niniejszej rozprawy. Opis jest oparty na koncepcji racjonalnego 
agenta oraz formalizacji funkcjonowania agentów wprowadzonej przez Wooldridge’ a. 

Cechy charakterystyczne opisanych botów to: 
wyodrębnienie funkcji odpowiedzialnych za percepcję bota, 
istnienie stanu wewnętrznego bota, 

podział na akcje proste i złożone, 


podział wnioskowania na reaktywne i deliberatywne, 
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możliwość definiowania celów, motywacji i kontynuacji dla akcji złożonych. 

Boty «Bot, które zostały stworzone przez autora na potrzeby niniejszej rozprawy, 
funkcjonują zgodnie z opisanym w tym rozdziale schematem. Celem rozprawy jest prezentacja 
podziału reguł zachowania bota na ogólne i specyficzne oraz pokazanie korzyści płynących z 
zastosowania takiego podziału. Opis formalny nie zakłada natomiast wykorzystania reguł w 
celu podejmowania decyzji przez boty kBot. W kolejnym rozdziale zostanie przedstawiona 
implementacja botów wykorzystująca reguły decyzyjne i umożliwiająca ich podział na reguły 


ogólne i specyficzne. 


5. Realizacja botów «Bot 


W tym rozdziale zostanie przedstawiona implementacja sterownika botów «Bot. 


Implementacja ta jest wykonana według opisu zaprezentowanego w rozdziale 4. 


5.1. Zarys architektury sterownika botów kBot 


Diagram 5.1 przedstawia schemat architektury sterownika botów kBot. Wyszczególniono 
komponenty umożliwiające działanie botów «Bot: 
1. silnik gry, 

2. sterownik botów «Bot, 
3. interpreter skryptów wnioskowania. 

Każdy z tych komponentów charakteryzuje się innym wpływem na bota w grze i ma 
ona inne znaczenie dla programisty botów. Silnik gry symuluje środowisko gry i wymusza 
przestrzeganie zasad gry przez funkcjonujące w nim postacie. Silnik gry jest elementem 
niemodyfikowanym przez programistę. Sterownik botów kBot odpowiada za podejmowanie 
decyzji prostych 1 informowaniu o nich silnika gry. W ramach sterownika funkcjonują 
decyzje wysokopoziomowe oraz akcje złożone. Skrypt opisujący wnioskowanie stworzony 
przez programistę botów jest wykonywany przez interpreter, który jest elementem sterownika 
botów «Bot. W wyniku działania skryptu mogą być podejmowane decyzje wysokopoziomowe 
wykonywane przez sterownik bota. 

Percepcja jest warstwą pośrednią w dostępie do stanu środowiska gry (1). Jej zadaniem jest 
określanie do jakich informacji ma dostęp bot w odpowiednim momencie. 

Decyzje wysokopoziomowe są jednostkami, które są wykorzystywane do definiowania 
zachowania botów «Bot. Definiowanie zachowania jest przeprowadzane przez programistów 
tworzących skrypt w języku Prolog dla botów «Bot. W ramach decyzji wysokopoziomowych 
wybierana jest akcja złożona, która oddziałuje na środowisko gry poprzez wykonywanie akcji 
prostych (6). Akcja złożona jako dane wejściowe przyjmuje cel, będący składową decyzji 
złożonej, informacje o stanie środowiska gry, dostarczane za pośrednictwem percepcji (5), 
oraz informacje o stanie wewnętrznym bota (8). Wykonanie akcji prostej powoduje zmianę 


w środowisku gry (2). 
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Rysunek 5.1. Szkic zależności między elementami funkcjonalnymi realizującymi sterowanie botów 
KBot 


Procesy wnioskowania służą do podejmowania decyzji wysokopoziomowych (4) oraz 
zmiany stanu bota (7). Procesy te są zdefiniowane za pomocą skryptu i realizowane poprzez 
interpreter języka Prolog. 

Motywacja jest elementem decyzji wysokopoziomowej służącym do określania w jakich 
okolicznościach decyzja wysokopoziomowa powinna być realizowana przez bota. Innym 
elementem decyzji wysokopoziomowej jest kontynuacja. Jest ona decyzją wysokopoziomową 
podejmowaną po zrealizowaniu zawierającej ją decyzji wysokopoziomowej. Zarówno 
wnioskowanie, jak i motywacje oraz kontynuacje, mogą odczytywać wewnętrzny stan 
wewnętrzny bota (5 i 6) oraz informacje o stanie środowiska gry za pośrednictwem percepcji 


(3). 


5.2. Wnioskowanie i podejmowanie decyzji wysokopoziomowych przez 
bota «Bot 


Algorytm podejmowania decyzji wysokopoziomowych przez bota został zaprogramowany 
z użyciem programowania w logice. Skrypt w logice jest implementacją funkcji wnioskowania 
reaktywnego r, oraz funkcji wnioskowania deliberatywnego ry, przedstawionych w rozdziale 4. 
Działanie procesów wnioskowania polega na wykorzystaniu reguł postępowania, co powoduje 
podjęcie decyzji wysokopoziomowej dla bota. 

Reguły decyzyjne botów «Bot tworzą trzy grupy o różnym stopniu ogólności: 
1. ogólne reguły dla gry Counter-Strike, 
2. reguły dla typu planszy: AS, DE lub CS (por. rozdz. 1.2.3), 


102 


3. reguły dla konkretnej planszy. 
Boty kBot preferują wybór reguł specyficznych nad ogólnymi. Te bardziej specyficzne są 
traktowane jako wyjątki od reguł ogólniejszych. 

Zgodnie z metodyką prezentowaną w rozprawie zachowanie botów «Bot można 
specjalizować poprzez definiowanie reguł postępowania, będących wyjątkami od ogólnych 
reguł postępowania w grze. Przykładowo, programista chcąc wyspecjalizować zachowanie 
botów do pewnej planszy, definiuje reguły w kategorii reguł specyficznych dla planszy. 

Wnioskowanie reaktywne i deliberatywne są wykonywane przez sterownik botów poprzez 
żądanie udowodnienia odpowiedniego predykatu-celu przez interpreter języka Prolog. W 
przypadku wnioskowania deliberatywnego jest to cel do_reasoning/1, a w przypadku 
wnioskowania reaktywnego jest to cel do_reflex_reasoning/1. Oba cele posiadają 
jeden argument, który musi być uzgodniony w momencie wywołania z identyfikatorem bota, 
dla którego ma być przeprowadzone wnioskowanie. 

Wspomniana wcześniej hierarchia ogólności reguł jest realizowana poprzez 


następujące reguły w skrypcie w logice gdzie map_inst_do_reasoning jest 


Listing 5.1. Organizacja reguł wnioskowania w grupy o różnych stopniach ogólności. 








do_reasoning(Id) :- map_inst_do_reasoning(Id), !. 
do_reasoning(Id) :- map_type_do_reasoning(Id), !. 
do_reasoning(Id) :- game_do_reasoning(Id). 





wnioskowaniem dla konkretnej planszy, map_type_do_reasoning — dla typu planszy, 
a game_do_reasoning — ogólnym wnioskowaniem dla gry Counter-Strike. Zgodnie z 
semantyką języka Prolog wnioskowanie odbywa się z użyciem reguł w takiej kolejności, 
która jest zapisana w skrypcie. Dzięki zapisowi z użyciem odcięcia pomyślne użycie reguły 
szczegółowej powoduje odstąpienie od prób przeprowadzenia dowodu wnioskowania z 
użyciem reguł ogólniejszych. 

W analogiczny sposób zrealizowana jest hierarchia ogólności reguł wnioskowania 


reaktywnego. 


5.3. Integracja botów kBot z interpreterem języka Prolog 


Boty «Bot są rozwinięciem botów E/POD], zaimplementowanych z użyciem języka C++. 
Nie jest to język programowania w logice, dlatego autor w ramach prac nad rozprawą 


wbudował do botów «Bot interpreter języka Prolog. Jako implementację interpretera 





wybrano SWI-Prolog[64] — ta implementacja spełnia kryteria wydajności dla botów kBot 


przyjęte w ramach rozprawy (patrz rozdz. 6.2.1). 
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Interpreter języka Prolog jest zintegrowany ze sterownikiem botów «Bot dzięki API 





ułatwiającemu używanie SWI-Prolog z programami tworzonymi w języku C++. Sam 
interpreter jest uruchamiany jako biblioteka ładowana dynamicznie. W sterowniku botów kBot 
funkcjonuje pojedyncza instancja tego interpretera, co jest realizowane w kodzie źródłowym 
poprzez wykorzystanie wzorca „Singleton”. Listing 5.2 przedstawia metodę inicjującą obiekt 


interpretera. 


Listing 5.2. Inicjowanie interpretera języka Prolog. 


PlEngine* e = 0; 
void ReasoningByProlog::initInterpreter() { 


int ac = 0; 

char* av[10]; 

av[ac++] = "swipl"; 
av[ac++] = "——nodebug"; 
av[ac++] = "—nosignals"; 


av[ac] = NULL; 
putenv ("SWI_HOME_DIR=/usr/1lib/swi—prolog"); 
try { 
if (e) { 
Logger:: getInstance()—>log("Notice: interpreter already allocated\n"); 
) else | 
Logger:: getInstance ()—>log(" Attempting to load interpreterin"); 
e = new PlEngine(ac, av); 
std :: stringstream ss (std::stringstream::in | std::stringstream:: out); 
PlTermv args(1); 
args[0] = "bot.pl"; 
PlQuery pq("consult", args); 
if (pq.next_solution()) { 
ss << "Command OK\n"; 
} else { 
ss << "Command failed\n"; 
} 


Logger:: getInstance ()—>log("Consult: %s\n", ss.str().c_str()); 


Logger:: getInstance ()—>log("Interpreter loaded succesfully \n"); 
} catch (PIException& ex) { 

Logger:: getInstance ()—>log("Failed to load interpreter\n"); 

throw; 


Na obiekt interpretera wskazuje wskaźnik e. Dostęp do tego obiektu odbywa się za 
pośrednictwem statycznych metod klasy ReasoningByProlog, która w tym przypadku 
pełni rolę fasady. Obiekt interpretera jest tworzony w linii 15. Jako parametry jest 
przekazywany zestaw flag wiersza poleceń. Tutaj są jest to flaga nodebug, która wyłącza 
śledzenie wykonania skryptów, oraz flaga nosignal, która powoduje, że obiekt interpretera 
nie reaguje na sygnały systemu operacyjnego. Po inicjacji wykonywane jest pierwsze polecenie 
polegające na wczytaniu skryptu odpowiedzialnego za funkcjonowanie bota. Poleceniem tym 
jest consult (’bot.pl’). Następnie polecenie to jest zgłaszane do wykonania przez 


interpreter w liniach 18-20 na listingu. 
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Listing 5.3 przedstawia metodę, która wykonuje zapytanie w interpreterze, ale nie zwraca 
jego rezultatów. Metoda ta służy do wywoływania reguł w skrypcie botów «Bot. Celem tych 


reguł jest zmiana stanu wewnętrznego bota lub zmiana decyzji wysokopoziomowej. 


Listing 5.3. Wykonanie zapytania przez interpreter języka Prolog. 


std::string ReasoningByProlog :: executeCommand ( 
const std::string& cname, const PITermv% cmd_args) { 
if (e) { 
std::stringstream ss (std::stringstream::in | std::stringstream:: out); 
try { 
PlQuery pq(cname.c_str(), cmd_args); 
if (pq.next_solution()) { 
ss << "Command OK\n"; 
} else I 
ss << "Command failed\n"; 
) 
catch (PlExceptiont e) { 
ss << (char*) e << std::endl; 
ss << "Command errorin"; 
) 
return ss.str(); 
) else | 
return "No interpreter\n"; 


~ 


Zaprezentowana metoda przyjmuje jako parametr o nazwie cname napis będący nazwą 
reguły, której dowód ma być przeprowadzony w interpreterze. Drugim parametrem jest lista 
argumentów tego zapytania. Przykładowo, przy wywołaniu wnioskowania deliberatywnego 
parametr cname ma wartość ’ do_reasoning', a argument cmd_args jest atomem języka 
Prolog identyfikującym bota, którego dotyczy polecenie. 

W liniach 8-9 jest wykonywane zapytanie w interpreterze i dalej, w zależności od wyniku, 


konstruowana jest odpowiedź o tym, czy zapytanie się powiodło. 


5.4. Realizacja percepcji 


W podrozdziale 4.2.2 została wprowadzona definicja zbioru obserwacji Świata gry — O. 
W przypadku botów «Bot zbiór ten jest obliczany z użyciem funkcji, które odczytują stan 
środowiska gry i zwracają pewne informacje, które składają się na obserwację środowiska 
gry. Funkcje te dostarczają informacji na temat widzenia przeciwników, słyszenia odgłosów 
wystrzałów lub kroków przeciwnika, widzenia broni leżącej na ziemi, położenia w przestrzeni, 
itp. Niektóre z tych informacji, zwłaszcza te które są często używane, są obliczane przed 
uruchomieniem algorytmu podejmowania decyzji przez bota i zapamiętywane w strukturze 
zawierającej informacje o bocie. 

Część z informacji obliczanych przez te funkcje może być wykorzystywana w skrypcie w 


logice za pośrednictwem predykatów natywnych. Są to predykaty, które wywołują funkcje 


105 


spoza interpretera języka Prolog. Moga one wywoływać funkcje dostarczające informacje o 
świecie gry lub odczytywać dane obliczone przez te funkcje. 

Przykładem predykatu pełniącego rolę percepcji jest see_bot/2. Jeżeli można 
udowodnić see_bot (botl, bot2), oznacza to, że postać bot_1 widzi w grze postać 
bot_2. see_bot/2 jest przykładem predykatu, który można dowodzić korzystając z 
nieuzgodnionych zmiennych, np. w przypadku dowodu see_bot (botl, X), zmienna X 
zostanie uzgodniona z pewną postacią widzianą przez postać bot_1. Szukając wszystkich 
termów uzgadnialnych ze zmienną X w przykładzie powyżej (np. za pomocą predykatu 
findall/3) można poznać zbiór wszystkich postaci, które widzi w środowisku gry postać 
o identyfikatorze bot_1. 

Przykładem predykatu, który odwołuje się do szukania wszystkich uzgodnień w predykacie 
natywnym, jest predykat hostile_agents/2. Zadaniem tego predykatu jest znalezienie 
zbioru wrogich postaci widzianych przez bota. Definicja tego predykatu jest przedstawiona na 


listingu 5.4. 


Listing 5.4. Fragment kodu odpowiedzialny za znajdowanie wrogich postaci w zasięgu wzroku. 





hostile_agents(BotId, L) :- 

findall(X, hostile visible (BotlId, X), L). 
hostile _visible(Botld, X) :- 

see _bot (BotId, X), is _alive(X), opposing_team(BotId, X). 
opposing_team(BotId, X) :- team(X, counter), team(BotId, terror). 
opposing_team(BotId, X) :- team(X, terror), team(BotId, counter). 





























Predykat hostile_agents jako parametr przyjmuje zmienną uzgodnioną z 
identyfikatorem bota. W wyniku przeprowadzenia dowodu tego predykatu zmienna Z 
zostaje uzgodniona z listą widzianych wrogich postaci, co jest określone predykatem 
hostile_visible. Ten predykat jest koniunkcją trzech warunków: widoczności 
postaci (see_bot), „bycia żywą” (is_alive) i przynależności do przeciwnej drużyny 
(opposing_team). 

Przykład realizacji natywnego predykatu percepcji dostarczającego informacji o środowisku 
gry bota jest przestawiony na listingu 5.5. Kod ten deklaruje predykat in_buyzone/1, 
który można wykorzystywać w skryptach realizujących algorytm podejmujący decyzje 


wysokopoziomowe przez bota. 








Predykat jest zadeklarowany w kodzie C++ za pomocą makra PREDICATE, pochodzącego 





z biblioteki SWI-Prolog. Makro to służy do deklarowania predykatów natywnych. Jego 
pierwszym argumentem jest nazwa predykatu, a drugim jego arność. 
Dowód predykatu in_buyzone(bot_1) kończy się powodzeniem, gdy bot o 


identyfikatorze bot_1 znajduje się w strefie zakupów. Działanie predykatu polega na 





odczytaniu pola bInBuyzone ze struktury zawierającej informacje o bocie. Pole to 
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Listing 5.5. Fragment kodu implementujacy natywny predykat percepcji sprawdzajacy czy bot 
jest w strefie zakupów. 


PREDICATE(in_buyzone, 1) { 
int vl = (int)Al; 
if (vl < 0 II vl >= gpGlobals—>maxClients) { 
throw std::invalid_argument("No bot with given index: " + std::to_string(vl)); 


} 
if (bots[vl].bInBuyzone) { 
PL_succeed; 
} else { 
PL_fail; 
} 
} 


jest zmienną logiczną, ustawianą przed uruchomieniem algorytmu podejmowania decyzji 
wysokopoziomowych. W zależności od prawdziwości tej zmiennej dowód predykatu kończy 
się sukcesem (wywołanie PL_succeed) lub porażką (PL_fail). Dowód predykatu kończy 
się błędem wykonania, poprzez zgłoszenie wyjątku, w sytuacji gdy jako parametr wyjściowy 
zostanie podany identyfikator nie odpowiadający żadnemu botu. 

Przykład natywnego predykatu percepcji, który wywołuje funkcję symulującą percepcję 


bota jest zaprezentowany na listingu 5.6. 


Listing 5.6. Fragment kodu implementujący predykat percepcji sprawdzający czy na Ścieżce 
ruchu bota znajduje się obiekt, który może zostać zniszczony. 


PREDICATE( breakable_blocking , 1) { 
int vl = (int)Al; 
if (vl < 0 II vl >= gpGlobals—>maxClients) { 
throw std::invalid_argument ( 
"No bot with given index: " + std::to_string(vl)); 


} 
TraceResult tr; 
edict_t *pBreak = BotFindBreakable(&bots[vl], tr); 
if (pBreak != NULL) { 
PL_succeed; 
} else { 
PL_fail; 
} 
} 


Predykat breakable_blocking wywołuje funkcję BotFindBreakable, która 
szuka w zasięgu wzroku obiektów, które mogą blokować Ścieżkę ruchu i jest możliwe ich 
zniszczenie. Argumentami tej funkcji są identyfikator bota oraz struktura opisujące opcje 
wyszukiwania (w przykładzie są wybrane domyślne opcje). Wynikiem działania jest struktura 
opisująca obiekt blokujący ruch. 

Zarówno kod z listingu 5.5 jak i 5.6 dostarczają informacji o środowisku gry. Jednak 
predykat in_buyzone odczytuje informacje wchodzące w skład stanu środowiska gry, a 
predykat breakable_blocking oblicza te informacje na podstawie stanu środowiska gry. 

Z uwagi na założenie o zamkniętym Świecie predykaty odwołujące się do percepcji 


mają charakter epistemiczny, tj. interpretuje się je jako percepcję postaci, a nie jako 
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stan środowiska. Na przykład niepowodzenie dowodu wyżej wymienionego predykatu 
breakable_blocking nie oznacza, ze na ścieżce ruchu bota, która może być bardzo długa, 
nie ma obiektów blokujących ruch, które mogą być zniszczone. Niepowodzenie to oznacza 


jedynie brak wiedzy o tego typu obiektach. 


5.5. Wykorzystanie stanu wewnętrznego 














W rozdziale 4.3.3 I jest zbiorem stanów wewnętrznych bota. Na zbiór ten składają się 
dane zawarte w interpreterze skryptów oraz w pamięci sterownika bota. Informacje, które 
składają się na stan wewnętrzny bota i znajdują się poza interpreterem skryptów, zawarte są w 
strukturach zdefiniowanych w C++. Te informacje są związane ze stanem procesu decyzyjnego 
bota. Jest w nich zawarta informacja na temat podjętej decyzji wysokopoziomowej, czyli 
akcji złożonej oraz jej celu, motywacji i kontynuacji. Realizacje tych elementów zostaną 
przedstawione w podrozdziałach 5.6 - 5.8. 

Informacje wykorzystywane przez wnioskowanie reaktywne (r,) i deliberatywne (rq) 


zawarte są w interpreterze skryptów. Informacje te są dodawane i kasowane za pomocą 





predykatów assert/1 i retract/1. Predykaty są etykietowane identyfikatorami botów, 
ponieważ sterownik botów «Bot wykorzystuje jedną instancję interpretera, która przechowuje 
informacje o stanie wewnętrznym wszystkich botów w grze. Stan wewnętrzny bota to 
informacje reprezentujące jego wiedzę, preferencje oraz przekonania. 

Predykaty reprezentujące wiedzę są ważne zazwyczaj przez pewien ograniczony okres 
obowiązywania. Można wyróżnić dwa typy okresów obowiązywania dla takich predykatów: w 
obrębie meczu oraz w obrębie rundy. Po upłynięciu swojego okresu obowiązywania predykaty 
są kasowane. 

Predykaty z okresem obowiązywania w obrębie rundy są wykorzystywane do implementacji 
zachowań, które bot musi wykonywać co najwyżej raz w każdej rundzie, np. decydowanie o 
kupnie broni, podkładanie bomby, początkowy podział na grupy i wstępne planowanie. Dzięki 
temu programista może odnotowywać, ile razy bot podjął daną decyzję wysokopoziomową w 
ciągu rundy. 

Predykaty z okresem obowiązywania w obrębie meczu mogą być wykorzystywane do 
zapamiętywania decyzji drużyny przeciwnej w celu adaptacji własnej taktyki działania. Do 
tej kategorii zaliczają się również predykaty reprezentujące wiedzę o grafie nawigacyjnym 
(patrz rozdz. 3.2.3), zawierającym informacje na temat punktów nawigacyjnych i połączeniach 
między nimi. Są one wykorzystywane do wnioskowania o poruszaniu się, co jest pomocne przy 


układaniu planów. 
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5.6. Realizacja akcji złożonych 


Do implementacji akcji złożonych botów «Bot zostały wykorzystane akcje złożone botów 
E[POD]. W kodzie źródłowym botów E/POD] istnieje wprowadzony wyraźny podział na akcje 
proste i złożone [69]. W ramach prac nad botem «Bot podział ten został wzmocniony poprzez 
refaktoryzację kodu źródłowego, odpowiedzialnego za realizację akcji złożonych, do postaci 
zgodnej z paradygmatem programowania obiektowego. 

Każda akcja złożona dziedziczy z klasy bazowej Task. Klasa ta definiuje wirtualną metodę 


której zadaniem jest wybór akcji prostej dla bota, który jest parametrem wywołania metody — 


virtual ActionFlags execTask (epb::bot::EPODbot *bot) = 0; 








bot. Każda akcja złożona dziedziczy z klasy Task i definiuje metodę execTask. 

Akcja prosta zawiera informacje na temat kierunku w którym ma ruszyć się bot, wektorze, 
wzdłuż którego będzie celować, wyborze broni, itp. Informacje określające akcję prostą są 
zapamiętywane w strukturze reprezentującej bota. Podjęcie decyzji niskopoziomowej polega 
na skonstruowaniu akcji prostej na podstawie tych informacji i przesłaniu jej do silnika gry. 
Ten sposób działania charakteryzuje się słabą przejrzystością działania kodu, jednak został 
zapożyczony z bota E/POD] i nie był zmieniany w ramach pracy nad botem «Bot. 

Jako przykład akcji złożonej zostanie zaprezentowana akcja PlantBombTask. Polega 
ona na uzbrojeniu bomby przez postać z drużyny terrorystów. Gracz wykonuje tę akcję poprzez 
kucnięcie w miejscu, w którym może zostać położona bomba, wybór bomby jako broni i 
wciśnięcie przycisku „strzał” przez ok. 5 sekund. Bot podkłada bombę w ten sam sposób. 
Listing 5.7 przedstawia kod metody PlantBombTask::execTask. 

Powyższy kod działa w następujący sposób. Gdy bot uzbraja bombę krócej niż przez pewien 
ustalony czas i ma bombę w ręku (warunek w liniach 6-7) to kontynuuje uzbrajanie bomby 
poprzez: wybór bomby jako broni (linia 8), kucanie (linia 9) i wciskanie klawisza ,,strzat” 
(linia 10). Podczas wykonywania tej akcji złożonej blokowane są wszystkie ruchy bota (linie 
11-14). Niespełnienie warunku zawartego w liniach 6-7 jest interpretowane jako zakończenie 
zadania. W takim przypadku zadanie jest oznaczane jako zakończone (linia 17). Jeżeli 
w momencie zakończenia zadania bot nie posiada bomby, oznacza to zakończenie zadania 
sukcesem (warunek w linii 18). W takim przypadku bot informuje o uzbrojeniu bomby za 


pomocą komunikatu tekstowego (linie 20-21). 


5.7. Sposób definicji celów i motywacji 


W podrozdziale 4.3 cel oraz motywacja zostały zdefiniowane jako zbiory stanów 


wewnętrznych agenta. Reprezentacja celów lub motywacji w sposób jawny, poprzez wyliczenie 
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Listing 5.7. Kod metody execTask akcji PlantBombTask. 


ActionFlags PlantBombTask ::execTask(epb:: bot:: EPODbot *pBot) { 
ActionFlags result = AF_none; 
edict_t *pEdict = pBot—>pEdict; 


// We're still in the planting time and got the c4 ? 
if ((pBot—>f_bomb_time > gpGlobals—>time ) 
&& (pEdict—>v.weapons & (1 << CS_WEAPON_C4))) { 
SelectWeaponByName(pBot, "weapon_c4"); 
pEdict—>v. button |= IN DUCK; 
pEdict—>v. button |= IN ATTACK; 
result & !AF_move_to_goal; 
pBot—>bCheckTerrain = FALSE; 
pBot—>f_move_speed = 0; 
pBot—>f_sidemove_speed = 0; 
pelse 1 
// Done with planting 
pBot—>completeTask(true , "plant—task"); 
if (!( pEdict—>v.weapons & (1 << CS_WEAPON_C4))) { 
// Notify the Team of this heroic action 
strcpy (pBot—>szMiscStrings , "Planted the Bomb!\n"); 
BotPushMessageQueue(pBot , MSG_CS_TEAMSAY) ; 


} 
} 


return result; 


ich wszystkich elementów, może stwarzać trudności w postaci konieczności zapisu w pamięci 
dużej ilości informacji. Z tego powodu wykorzystanie jawnej reprezentacji w sterowniku botów 
jest niepraktyczne, podobnie jak w przypadku percepcji. Konieczne jest więc korzystanie z 
reprezentacji niejawnej poprzez posługiwanie się opisem oznaczającym pewien zbiór stanów 
wewnętrznych. 

W implementacji botów «Bot w przypadku celów rolę takiego opisu pełnią parametry akcji 
złożonej, które są zależne od jej typu. Najczęściej są to parametry numeryczne, np. lokalizacja, 
do której bot ma się udać. W przypadku botów «Bot parametry akcji można wyrazić w postaci 
formuły logicznej, która jest spełniona przez stany bota oznaczające zakończenie wykonania 
akcji sukcesem. Lokalizacja jest parametrem akcji złożonej, polegającej na przemieszczaniu 
się. Takiemu parametrowi można przyporządkować formułę logiczną, która jest prawdziwa, 
gdy położenie bota jest takie, jak określane przez parametr akcji przemieszczania się. Formuły 
logiczne będące odwzorowaniami celów są wykorzystywane w komunikacji pomiędzy botami 
kBot. Mogą one przekazywać między sobą informacje o swoich celach, wyrażając je jako 
formuły logiczne i podejmować decyzje o swoich działaniach w oparciu o wnioskowanie o 
celach innych botów. 

Istnieją akcje złożone, dla których jest trudno w oczywisty sposób sprecyzować cel. 
Przykładem takiej akcji złożonej jest symulacja reakcji na granat hukowy. Bot symuluje 
zachowanie polegające na chwilowej utracie wzroku, dezorientacji lub panice, ponieważ takie 


zachowania występują u człowieka. Jest to przykład wspomnianej wcześniej różnicy między 
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podejściami „racjonalnego działania” i „działania jak człowiek” w systemach ze sztuczną 
inteligencją. 

Rolę opisu stanów składających się na motywację pełni formuła logiczna, która 
jest spełniona w przez pewne stany wewnętrzne bota. Zgodnie z formalnym opisem 
funkcjonowania bota, w każdym cyklu decyzyjnym sprawdzane jest, czy motywacja jest 
spełniona. Jeśli nie, to bot przerywa wykonywanie akcji złożonej, z którą była związana 
motywacja, i przeprowadza wnioskowanie deliberatywne w celu znalezienia nowej decyzji 
wysokopoziomowej. Sprawdzenie, czy motywacja zachodzi, polega na próbie przeprowadzenia 
dowodu formuły stanowiącej motywację na podstawie informacji dostępnych mechanizmom 


wnioskowania bota. Kod realizujący to sprawdzenie jest przedstawiony na listingu 5.8. 


Listing 5.8. Kod metody realizujący sprawdzenie spełnienia motywacji. 


bool LogicalMotivation :: motivationHolds() { 
PlTerm nt = motivation_predicate.reconstruct(); 
PlQuery pq("call", nt); 


if (pq.next_solution()) { 
réturn true; 

t bee. 1 
return false; 


} 


Klasa reprezentująca = motywacje wykorzystujące warunki logiczne to 





LogicalMotivation. Jej metoda motivationHolds określa czy motywacja jest 
spełniona. Klasa ta przyjmuje w konstruktorze parametr będący termem, którego dowód 
jest przeprowadzony przy każdym wywołaniu metody motivationHolds. Powyższy 
kod konstruuje term (linia 2), którego dowód jest przeprowadzany dzięki użyciu predykatu 
call/1 (linia 3). Gdy dowód predykatu (linia 4) się powodzi, motywacja jest spełniona, w 
przeciwnym przypadku nie jest ona spełniona. 

Motywacja kolektywna, będąca elementem tworzenia współpracy między agentami 
(por. 4.4), mogłaby być konstruowana jako formuła, będąca koniunkcją motywacji 
indywidualnych. Przy określaniu, czy motywacja jest spełniona dla jakiegoś bota, konieczne 
byłoby stwierdzenie, czy zachodzą indywidualne motywacje dla innych botów. Ponieważ 
jednak motywacje są obliczane na podstawie stanu wewnętrznego bota, obliczanie motywacji 
kolektywnej zdefiniowanej w ten sposób naruszałoby autonomię botów, gdyż odczytywałyby 
one wzajemnie swoje stany. Alternatywą jest wykorzystanie w tym celu komunikacji pomiędzy 
botami, poprzez wzajemne odpytywanie się o to, czy zachodzi motywacja do wykonania 
wspólnego zadania. Rozwiązanie to zostało wykorzystane do implementacji botów kBot. Jest 
ono przedstawione w punkcie 5.10. 

Istnieją pewne rodzaje motywacji, które nie odwołują się do stanów wewnętrznych innych 
botów, a jedynie do faktów, które są obserwowalne przez każdą z postaci w obrębie tej samej 


drużyny. Motywacje budowane w oparciu o statystyki rozgrywki lub informacje o tym, które z 
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postaci żyją, mają taką własność. Przy określaniu, czy motywacje tego typu są spełnione, nie 
jest konieczne wykorzystywanie komunikacji między botami. Tego typu motywacje są również 
wykorzystywane przy definiowaniu współpracy między botami. Na przykład boty mogą 
zakładać, że bot, zobowiązawszy się do zrealizowania pewnego celu, będzie dążył do niego 
za wszelką cenę — w tym przypadku jedynie unicestwienie takiego bota może spowodować że 


jego motywacja nie będzie zachodzić. 


5.8. Sposób definicji kontynuacji 


Kontynuacja została zdefiniowana w rozdziale 4.3 jako decyzja wysokopoziomowa, 
która jest automatycznie podejmowana w przypadku zrealizowania zawierającej ją decyzji 
wysokopoziomowej, tj. kiedy akcja złożona doprowadzi bota do pewnego celu, ustalonego 
w ramach decyzji wysokopoziomowej. 

Kontynuacja jest elementem decyzji wysokopoziomowej. Jest ona realizowana jako term 
języka Prolog, którego dowód jest przeprowadzany po zakończeniu sukcesem wykonania 
akcji złożonej. Przeznaczeniem kontynuacji jest przeprowadzenie wnioskowania w celu 
wyboru nowej decyzji. Szczególnym przypadkiem takiego wnioskowania jest bezwarunkowy 
wybór pewnej decyzji wysokopoziomowej. Taki zabieg jest stosowany w celu realizacji 
sekwencji akcji złożonych wykonywanych przez bota. Na przykład w sekwencji typu „idź 
do drzwi i otwórz je” można wyróżnić dwie akcje: przemieszczania się i otwierania drzwi. 

Kontynuacja, która wykorzystuje wnioskowanie w celu wyboru kolejnej decyzji 


wysokopoziomowej, jest realizowana przez klasę LogicalContinuation. Metoda tej 





klasy doContinue jest wykonywana po zakończeniu realizacji decyzji wysokopoziomowej, 


która zawiera tę kontynuację. Implementacja tej metody została przedstawiona na listingu 5.9. 


Listing 5.9. Fragment kodu realizujący kontynuację. 


void LogicalContinuation:: doContinue() { 


PlTerm nt = this—>term.reconstruct(); 
PlQuery pq("call", nt); 
if (!pq.next_solution()) { 
Logger:: getInstance ()—>consoleLog("Continuation broken\n"); 


} 
} 


Idea metody LogicalContinuation::doContinue jest podobna do metody 





LogicalMotivation: :motivationHolds. Działanie obu metod polega na 





przeprowadzenia dowodu pewnego predykatu przez interpreter języka Prolog. W przypadku 
kontynuacji oczekuje się jednak, że dowód predykatu zakończy się sukcesem. Wazniejszy 
jest jednak efekt uboczny w postaci modyfikacji stanu procesu decyzyjnego, tj. powinna być 


podjęta nowa decyzja wysokopoziomowa. 
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5.9. Realizacja wnioskowania na poziomie decyzji wysokopoziomowych 


Decyzje wysokopoziomowe składają się z akcji złożonej, jej celu oraz motywacji 1 
kontynuacji, omówionych w rozdziałach 5.6 - 5.8. Decyzje wysokopoziomowe są wybierane 
przez wnioskowanie reaktywne (r,) i deliberatywne (rg). Te procesy wnioskowania są 
definiowane za pomocą skryptu w logice. Ponieważ decyzje wysokopoziomowe są strukturami 
zdefiniowanymi w języku C++ i są wykonywane przez bota, niezależnie od działania 
interpretera języka Prolog, zdefiniowane są predykaty natywne pozwalające na zmienianie 
wybranej decyzji wysokopoziomowej. Programista tworzący skrypt definiujący działanie bota 
może z nich korzystać. 


Dostępny jest predykat! który powoduje skonstruowanie decyzji wysokopoziomowej dla 








action(Id, ActionId, Goal, Motivation, Continuation) 





bota z identyfikatorem Id. Decyzja ta składa się z akcji złożonej o typie określonym 





przez identyfikator ActionId, celu Goal, motywacji Motivation oraz kontynuacji 
Continuation. Wszystkie z wyżej wymienionych zmiennych powinny być uzgodnione w 
momencie przeprowadzania dowodu tego predykatu. Cel akcji zależy od jej typu, np. dla akcji 
przemieszczania się jest to punkt na planszy, natomiast parametrem tej akcji jest identyfikator 
punktu nawigacyjnego. Motywacja i kontynuacja mogą być dowolnymi termami. 

W celu ułatwienia korzystania z tego predykatu zdefiniowane są predykaty pomocnicze, 
w których nazwie jest zawarta nazwa typu akcji złożonej, którą wybierają dla decyzji 


wysokopoziomowej, np. 





action _seek_cover(Id, Goal, Motivation, Continuation) :- 





action(Id, seek _cover, Goal, Motivation, Continuation). 


Dla takiego predykaty, wybierającego daną akcję złożoną, zdefiniowane są również 


predykaty o różnej arności, które nie wymagają podawania kontynuacji oraz motywacji. 





action_seek_cover(Id) :- 








action _seek_cover(Id, all _cost(lId)). 





action_seek_cover(Id, Motivation) :- 








action_seek_cover(Id, Motivation, do_nothing(Id)). 





action_seek_cover(Id, Motivation, Continuation) :- 





action_seek_cover(Id, nearest, Motivation, Continuation). 


' predykat ten powinien nazywać się decision — nazwa nie została zmieniona z przyczyn historycznych. 
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Dowód predykatu action_seek_cover/3 powoduje stworzenie decyzji 





wysokopoziomowej dla bota z identyfikatorem Id. Decyzja zawiera akcję złożoną polegającą 
na szukaniu najbliższej kryjówki. Dla akcji jest wybierany cel nearest, polegający na 
wyborze najbliższej kryjówki. Predykat action_seek_cover/3 przyjmuje motywację i 
kontynuację, które są przekazywane jako parametry do tworzonej decyzji wysokopoziomowej. 
Predykat action_seek_cover/2 nie wymaga przekazywania kontynuacji, ponieważ 
wybiera pustą kontynuację (do_nothing). Predykat action_seek_cover/1 wymaga 
podania jedynie identyfikatora bota, wybierana jest motywacja, która jest zawsze spełniona 
(all_cost) oraz pusta kontynuacja. 

W języku Prolog dowód predykatu z pomocą pewnej reguły jest przeprowadzany poprzez 
próbę dowodu kolejnych predykatów zdefiniowanych w tej regule. Jeżeli użyty zostanie 
predykat mający efekt uboczny, to niezależnie od możliwości wykonania innych predykatów w 
regule, jego skutek nie zostanie wycofany. Predykaty rozpoczynające wykonanie akcji złożonej 
mają efekt uboczny, ponieważ zmieniają stan procesu decyzyjnego bota. Dlatego ich wywołanie 
powinno mieć miejsce w momencie, gdy sprawdzono już wszystkie warunki w regule, które 
mogą spowodować niepowodzenie dowodu. W celu ilustracji istotności kolejności wywołania 


predykatów w regułach decyzyjnych rozważmy reguły przedstawione na listingach 5.10 15.11. 


Listing 5.10. Poprawna kolejność wywołania predykatów. 











do_reasoning(Id) :- see _enemy(Id), action_seek_cover(Id). 


Listing 5.11. Niepoprawna kolejność wywołania predykatów. 











do_reasoning(Id) :- action_seek_cover(Id), see _enemy (Id). 


W przypadku kodu na listingu 5.10, po przeprowadzeniu dowodu predykatu 
action_seek_cover/1 dowód predykatu do_reasoning/1 kończy się sukcesem, bo 
action_seek_cover/1 jest ostatnim predykatem w regule. 


W przypadku kodu na listingu 5.11 po przeprowadzeniu dowodu predykatu 





action_seek_cover/1 sprawdzany jest jeszcze warunek określony predykatem 





see_enemy. Jeśli warunek ten jest niespełniony to bot i tak podejmie decyzję z akcją 
seek_cover, ponieważ został zmodyfikowany już stan jego procesu decyzyjnego. Z uwagi 
na występowanie efektów ubocznych przy dowodzie predykatów zmieniających stan procesu 
decyzyjnego, reguła zaprezentowana na listingu 5.11 jest błędna z punktu widzenia metodyki 
prezentowanej w rozprawie. 

Predykaty do zmiany decyzji wysokopoziomowych stanowią kluczowy element działania 
kontynuacji (rozdz. 5.8). Przeprowadzenie dowodu predykatu, będącego kontynuacją, powinno 
wywoływać predykat zmieniający decyzję wysokopoziomową, aby kontynuacja działała w 


prawidłowy sposób. W najprostszym przypadku, predykatem stanowiącym kontynuację może 


114 
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być po prostu predykat zmieniający decyzję wysokopoziomową. Przykład takiego zastosowania 


kontynuacji znajduje się na listingu 5.12. 


Listing 5.12. Fragment kodu wykorzystujący kontynuację. 








do_reasoning(Id) :- action_goto(Id, wp(134), 
all _ cost (Id), 
action_camp (Id)). 











W zaprezentowanym przykładzie, dla bota z identyfikatorem Id, poprzez predykat 
action_goto/4, tworzona jest akcja przemieszczenia się do punktu nawigacyjnego o 
numerze 134. Jako motywacja wybierana jest domyśla motywacja all_cost, która 
zawsze jest spełniona. Kontynuacją podjętej decyzji wysokopoziomowej jest predykat 
action_camp, który powoduje podjęcie przez bota akcję kampowania z domyślnym celem, 
motywacją i kontynuacją. Konstrukcję z listingu 5.12 należy czytać jako „idź do punktu 134, a 
następnie kampuj”. 


Bardziej skomplikowane zastosowanie kontynuacji zostało przedstawione na listingu 5.13. 


Listing 5.13. Fragment kodu wykorzystujący kontynuację. 


olo 


wykonanie akcji wyniklej z wnioskowania 

















do_reasoning(Id) :- action hunt (Id, EnemyID, 
all _ cost (Id), 
after hunt (Id)). 








oo 


wnioskowanie wywolywane jako kontynuacja 
after _hunt(ld) :- is _hurt(lId), !, 
action seek _cover(Id, all cost (lId)). 




















after_hunt (Id) :- low ammo(Id), time(T), T < 10, 
action_seek_buyzone(Id, all_cost(Id), action_buy(Id, ammo)). 

















W zaprezentowanym przyktadzie, wywotanie do_reasoning/1 tworzy akcje Hunt za 
posrednictwem predykatu action_hunt/4. Jest to akcja polegajaca na szukaniu postaci 
należących do drużyny przeciwnej i eliminowaniu ich. Akcja ta jest stworzona z motywacją 
all_cost, która jest zawsze spełniona, i kontynuacją after _hunt/1. Wywołanie 
tej kontynuacji powoduje przeprowadzenie wnioskowania, które zawiera zdefiniowane 
dwie reguły postępowania. Pierwsza z nich tworzy akcję SeekCover (predykat 
action_seek_cover), gdy bot stracił punkty życia (predykat is_hurt/1). Druga 
reguła zachodzi, gdy bot nie stracił punktów życia. Wówczas sprawdza się czy ma 
mało amunicji (predykat low _ammo/1) i czy nie upłynęło dużo czasu od początku rundy 


(predykat time/1). Jeżeli te dwa warunki są spełnione to jest rozpoczynana akcja szukania 
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strefy kupowania broni (predykat action_seek_buyzone/3. Akcja ta zawiera również 
kontynuację polegającą na natychmiastowym uruchomieniu akcji kupowania amunicji. W 
przypadku, gdy kontynuacja nie spowoduje podjęcia nowej decyzji wysokopoziomowej 
przeprowadzanie jest wnioskowanie deliberatywne w celu znalezienia takiej decyzji. W 


przedstawionym przykładzie taka sytuacja ma miejsce, gdy nie spełniony jest warunek 








is _hurt (Id) oraz low ammo (Id). 


5.10. Sposób realizacji komunikacji i współpracy botów «Bot 


Boty «Bot reagują na wiadomości radiowe, które są mechanizmem gry Counter-Strike. 
Informacje o usłyszeniu wiadomości radiowych są częścią obserwacji Świata gry. Bot 
reaguje na wiadomości radiowe dzięki wnioskowaniu reaktywnemu. Ponieważ jest ono 
przeprowadzone w każdym cyklu decyzyjnym, bot może dzięki temu zareagować na komunikat 
radiowy praktycznie bezpośrednio po jego usłyszeniu. 

Bot może używać wiadomości radiowych w celu komunikacji z innymi postaciami w grze. 
Zaletą takich komunikatów jest możliwość komunikacji z graczem. Bot potrafi też reagować 
na komunikaty nadawane przez graczy. Na przykład, jeśli gracz nada komunikat radiowy „za 
mną”, to niektóre z boty zaczną podążać za graczem. 

Sterownik botów «Bot zawiera mechanizm komunikacji pozwalający się komunikować 
botom jedynie między sobą. Komunikacja ta odbywa się za pośrednictwem interpretera 
skryptów języka Prolog. Sterownik przekazuje informacje pomiędzy botami poprzez 
zapisywanie informacji o otrzymaniu komunikatu jako termu składającego się na stan 
wewnętrzny bota, będącego odbiorcą komunikatu. Ten mechanizm komunikacji jest stosowany 
do komunikacji według reguł zdefiniowanych w skrypcie definiującym zachowanie botów. W 
skrypcie sterującym zachowaniem botów «Bot, przygotowanym w ramach niniejszej rozprawy, 
komunikacja jest wykorzystywana do podziału botów w ramach jednej drużyny na mniejsze 


zespoły i wyboru taktyki, według której ma postępować dany zespół. 


5.10.1. Szablon taktyki zespołowej 


Szablon taktyki zespołowej opisuje taktykę, która na drodze negocjacji może być wybrana 
do wykonania przez boty «Bot. Taktyka zespołowa składa się z opisu zachowań poszczególnych 
botów, które będą ją wykonywały. Do każdego opisu zachowań dla bota dołączony jest warunek 
wstępny, który musi być spełniony, aby bot mógł podjąć się wykonania tego działania w 
ramach taktyki. Opis zachowania bota to lista termów, które bot będzie kolejno wykorzystywać 
do wyboru decyzji wysokopoziomowych. Term ten zawiera informacje, które, wraz z 


identyfikatorem bota, wystarczają do określenia decyzji, która ma zostać przez niego podjęta. 
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Najczęściej jest to identyfikator akcji oraz jej cel. Motywacja i kontynuacja sa określone dla 
całej taktyki i są takie same dla każdej z decyzji składającej się na tę taktykę. 
Przykładowa deklaracja jednej z taktyk stosowanych na planszy cs_assault 


zaimplementowanych w bocie «Bot jest przedstawiona na listingu 5.14. 


Listing 5.14. Przykładowa deklaracja taktyki zespołowej. 


team _tactic( 

counter, [ 
bot_tactic([ 
mov(318), sync(pl), mov(206), mov(205), mov(200), mov(223), 
mov(397), mov(393), mov(95), sync(p2), 


groupup ([ 
camp(1), mov(101), mov(109), 
mov (214), mov(258), mov(400)])], 





assaultrifle), 
bot _tactic([ 
mov(258), sync(pl), mov(143), mov(150), mov(127), 





mov (385), sync(p2), 
groupup ([ 
camp(1), mov(101), mov(109), 
mov (214), mov(258), mov(400)])], 
assaultrifle) 


Term team_tactic jest deklaracją taktyki zespołowej. Pierwsza składowa counter 
oznacza, że jest to taktyka przeznaczona dla drużyny antyterrorystycznej. Drugą składową 
jest lista opisów zachowań dla botów w drużynie. Każdy opis takiego zachowania jest 
deklarowany za pomocą termu bot_tactic. Deklaracja ta zawiera listę termów, które 
oznaczają wykonanie pewnych akcji. W przedstawionym przykładzie są to: 

— mov/1, oznaczający ruch do punktu nawigacyjnego o danym numerze, 


— camp/ 1, oznaczający kampowanie przez pewien czas, 





— sync/1 (omówiony później), oznaczający synchronizację w wykonaniu taktyki, 

— groupup/1 (omówiony później), oznaczający wybór lidera, który będzie postępował 
zgodnie opisem zachowanie będącym parametrem tej akcji, a pozostałe boty będą podążały 
za liderem. 

Drugą składową termu bot_tactic, będącego opisem zachowania bota, jest warunek 
wstępny, który bot musi spełnić aby móc wybrać daną taktykę w obrębie zespołu. Jest to nazwa 
predykatu jednoargumentowego. Predykat ten przyjmuje identyfikator bota i jeśli możliwe jest 


jego dowiedzenie, oznacza to, że bot o danym identyfikatorze może wykonywać daną taktykę. 


117 


W przedstawionym przykładzie takim predykatem jest assaultrifle/1, który oznacza 


posiadanie lub możliwość zdobycia karabinu szturmowego. 


5.10.2. Negocjowanie taktyki zespołowej 


Taktyka zespołowa może być wykonywana jedynie w sytuacji, gdy potrzebne do jej 
wykonania boty zgadzają się na jej wykonanie. Proces, który do tego prowadzi, jest nazwany 
negocjowaniem taktyki. Proces ten jest realizowany poprzez akcję złożoną, w której boty 
proponują taktyki, jakie mogą wykonywać. 

Negocjowanie taktyki odbywa się z wykorzystaniem dynamicznego termu 
team_commitment, który należy interpretować jako zobowiązanie do wykonania taktyki. 
Boty komunikują między sobą zobowiązania do wykonania taktyki i każdy bot zapamiętuje, 
które zobowiązania są aktualne. 

Term team_commitment składa się z dwóch list: listy opisów działań możliwych do 
wyboru przez boty oraz listy opisów działań, które zostały już wybrane. Druga lista jest listą 
par składających się z identyfikatorów bota i opisów zachowań. Wprowadza się następujące 
nazewnictwo: 

— zobowiązanie puste — term team_ commitment, w którym lista opisów działań 
wybranych przez bota jest pusta, 

— zobowiązanie częściowe — term team_commitment, obie listy są niepuste, 

— zobowiązanie pełne — term team_commitment, w którym działań możliwych do wyboru 
jest pusta. 

Negocjacje zaczynają się od zobowiązań wyłącznie pustych. Te tworzone są na podstawie 
predefiniowanych szablonów taktyk zespołowych. Negocjacje prowadzone są turami. W każdej 
turze bot wybiera jedno niepełne zobowiązanie, w którym nie ma go na liście wybranych 
działań. Jeżeli spełnia warunek wstępny dla tego działania, to tworzy na jego podstawie 
nowe zobowiązanie, częściowe lub pełne. W momencie, gdy wybrane zostanie stworzone 
pełne zobowiązanie boty formują zespół 1 zaczynają postępować według opisu działania, do 
którego się zobowiązały w ramach przyjętej taktyki. Boty tworzące zespół przekazują innym 
botom komunikat o sformowaniu zespołu. Wtedy boty nie będące w zespole dezaktualizują 
zobowiązania częściowe, w których uczestniczą boty nadające ten komunikat. Anulowanie 
zobowiązań częściowych ma na celu zapobieganie sytuacji, w której ten sam bot wchodzi w 
skład wielu zespołów. 

Każde niepuste zobowiązanie jest tworzone poprzez wybór jednego opisu działania. 
Dokonanie wyboru polega na usunięciu opisu działania z listy działań możliwych do 
wyboru i wstawienie do listy wybranych działań termu assigned_tactic, zawierającego 
identyfikator bota i opis działania. 


Zobowiązania puste, częściowe i pełne zostały przedstawione na listingach 5.15 - 5.17. 
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Listing 5.15. Przykład pustego zobowiązania. 


team _commitment ([], I 
bot_tactic([mov(1)] 
bot _tactic([mov(2)], is alive), 
bot_tactic([mov(3)] 


, is alive), 











, is alive)]). 


Listing 5.16. Częściowe zobowiązanie. 


team _commitment ([ 
assigned _tactic(bot_1, [mov(1)]), 
assigned_tactic(bot_2, [mov(2)])], I 
bot_tactic([mov(3)], is_alive)]). 


Listing 5.17. Pełne zobowiązanie, prowadzące do uformowania zespołu. 


team _commitment ([ 
assigned tactic(bot_1, [mov(1)]) 
assigned tactic(bot_2, [mov(2)]) 
assigned tactic(bot_3, [mov(3)]) 


Przykład pustego zobowiązania jest przedstawiony na listingu 5.15. Przykład zawiera trzy 
taktyki polegające na ruchu do różnych punktów nawigacyjnych. Warunkiem wstępnym do 
podjęcia akcji przez bota jest „bycie żywym”. 

W wyniku negocjacji tworzone są przez boty zobowiązania częściowe. Przykład takiego 
zobowiązania jest zaprezentowany na listingu 5.16. W przykładowym zobowiązaniu dwie 
taktyki zostały wybrane przez boty o identyfikatorach bot__1 ibot_2, trzecia zaś może zostać 
wybrana przez innego bota w celu stworzenia nowego zobowiązania. Ostatecznie negocjacje 
prowadzą do pełnych zobowiązań, gdzie do każdej roli w drużynie jest przypisany pewien 
bot. Przykład takiego zobowiązania jest przedstawiony na listingu 5.17. Takie zobowiązanie 
prowadzi do powstania drużyny z wybraną taktyką. 

Pojawienie się pełnego zobowiązania powoduje, że każdy z botów, którego ono dotyczy, 
anuluje inne swoje zobowiązania częściowe. W tym celu wysyła innym botom komunikat 
informujący o sformowaniu zespołu, którego jest częścią. Na przykład, w momencie stworzenia 
pełnego zobowiązania zawierającego bota o identyfikatorze bot_1, anuluje on następujące 


zobowiązanie ponieważ został przypisany do niego opis działania 


team _commitment ([ 


assigned _tactic(bot_1, [mov(1)]), 
assigned _tactic(bot_2, [mov(2)])], I 
bot _tactic([mov(3)], is _alive)]). 


Zobowiązania niedotyczące bota bot_1, np. nie są kasowane w ramach anulowania 
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assigned_tactic(bot_1, [mov(1)]) 


team_commitment ([ 
assigned_tactic(bot_2, [mov(2)])], I 
bot_tactic([mov(1)], is_alive) ] 








bot_tactic([mov(3)], is_alive)]). 


zobowiązań przez bota bot__1. Dzięki temu inne boty mogą próbować przyłączyć się do tego 
zobowiązania. 

Negocjacje trwają przez pewien ograniczony czas. Boty, które w tym czasie nie wejdą w 
skład zespołów, grają bez stosowania zasad narzuconych przez zespół. Stosują wtedy reguły 


gry na danej planszy lub ogólniejsze zasady postępowania. 


5.10.3. Wykonywanie taktyki zespołowej 


Opis zachowania bota w taktyce zespołowej jest listą termów. W wyniku działania 
mechanizmu taktyki zespołowej każdy z tych termów jest zamieniany na decyzję złożoną 
podejmowaną przez bota. Elementy listy są przetwarzane po kolei. Każdorazowo podjęta 
decyzja wysokopoziomowa zawiera kontynuację, w wyniku której przetwarzana jest pozostała 
część listy. Natomiast motywacją w decyzji złożonej jest warunek postępowania wszystkich 
botów według przyjętej taktyki. Skutek tego jest taki że, gdy jeden z botów zginie, drużyna się 
rozpada. 

Wspomniane przetwarzanie listy, będącej opisem postępowania botów, jest realizowane za 
pomocą reguł w języku Prolog. Przetwarzanie listy termów opisujących działania botów w 
taktyce zespołowej odbywa się za pośrednictwem predykatów execute_tactics/3. W 
przykładzie na listingu 5.18 przedstawiona jest reguła stosowana do przetwarzania termów 


camp/1. Jest to term, który powoduje kampowanie przez bota, dla którego jest przetwarzany. 


Listing 5.18. Wykonywanie taktyki indywidualnej z użyciem kontynuacji. 





execute _tactics(ld, LTactic, Cmt) :- 
nth0(0, LTactic, camp (Where), Rest), 
action_camp (Id, Where, 








all _agents_commiting (Cmt), 





execute _tactics(ld, Rest, Cmt)). 


Predykat wbudowany nth0 powoduje oddzielenie pierwszego termu z listy LTactic. 
Jeżeli ten term jest uzgadnialny z camp (Where) to prowadzi to do wyboru akcji kampowania, 
wybierana jest motywacjaall_agents_commiting/1, która jest spełniona, gdy wszystkie 
boty w taktyce zespołowej ją wykonują. Kontynuacją jest nowe wywołanie predykatu 


execute_tactics/3 z lista termów Rest, będącą ogonem listy LTactic. Powoduje to 
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so 


dalsze przetwarzanie listy termów opisujących taktykę zespołową. Przetwarzanie funkcjonuje 
do momentu, gdy lista opisująca taktykę stanie się pusta. Wtedy postępowanie bota według 


taktyki zespołowej jest kończone. 


5.10.4. Akcje złożone dla agenta w taktyce zespołowej 


Boty kBot zawierają akcje złożone, które zostały wprowadzone z myślą o usprawnieniu 
wykonania taktyki zespołowej. 

Jedną z takich akcji złożonych jest akcja WaitForTask. Polega ona na oczekiwaniu 
na pewien warunek, który jest określony termem języka Prolog. Fragment tej akcji jest 


zaprezentowany na listingu 5.19. 


Listing 5.19. Fragmenty akcji WaitForTask. 


bool WaitForTask :: checkCondition() { 
ScopedPlFrame fr; 
PlTerm nt = this—>term_.reconstruct(); 
PlQuery pq("call", nt); 
return pq.next_solution(); 


} 


ActionFlags WaitForTask ::execTask(epb:: bot:: EPODbot *pBot) { 
if (this—>checkCondition()) { 
pBot—>completeTask(true , "sync—condition—met"); 
return AF_none; 


“~ 


else { 
return this—>Wait(pBot); 


Akcja ta zawiera term jezyka Prolog jako składową o nazwie term_. Zadaniem metody 
WaitForTask::checkCondition jest sprawdzenie, czy warunek opisany tym termem 
zachodzi dla danego stanu wewnętrznego bota. W tym celu tworzone jest zapytanie o dowód 
termu przechowywanego w składowej term_ (linie 3-4), następnie przeprowadzany jest dowód 
tego termu (linia 5) i zwracana jest informacja, czy term możliwy do dowiedzenia dla obecnego 
stanu wewnętrznego bota. 

Metoda WaitForTask::execTask jest zdefiniowana przez klasę bazową akcji jako 
metoda wirtualna. Jest ona wywoływana w celu podjęcia przez akcję decyzji niskopoziomowej. 
W przypadku akcji złożonej WaitForTask, implementacja tej metody wykorzystuje metodę 
checkCondition do sprawdzenia, czy warunek będący parametrem akcji zachodzi (linia 
9). Jeżeli tak, to akcja jest kończona sukcesem (linie 10-11). W przeciwnym przypadku bot 
wykonuje metodę Wait, która powoduje wykonywanie akcji kampowania (linia 13). 

W kontekście rozprawy akcja ta została wprowadzona w celu realizacji synchronizacji 
wykonania taktyki zespołowej. W liście akcji składających się na taktykę zespołową 
możliwe jest zdefiniowanie akcji synchronizacji poprzez użycie termu sync/1. Term 


ten przyjmuje jako parametr nazwę dla punktu synchronizacji. Bot, wykonując akcję 
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synchronizacji, oczekuje az inne boty w zespole przekroczą punkt synchronizacji o 
danej nazwie. Bot, przekraczając punkt synchronizacji, przekazuje innym botom 
komunikaty informujące o tym fakcie. Boty zapamiętują te informacje jako wiedzę 


o zakresie ważności w obrębie rundy, tj. jest zapamiętywana za pomocą wywołania 











assertz (round_know(Idl, sync(S, Id2))),gdzie Id1 jest identyfikatorem bota, 





który posiada informacje o fakcie sync (S, Id2). Fakt ten oznacza, że bot o identyfikatorze 





Id2 przekroczył punkt synchronizacji o nazwie S. Warunek, na który boty czekają to 


all bots_syncing(Id, S; BotsL) :- 
forall (member (IdB, BotsL), know(Id, sync(S, IdB))). 




















Warunek ten jest spełniony dla bota o identyfikatorze Id, gdy zostanie on poinformowany o 
tym, że każdy z botów w zespole przekroczył punkt synchronizacji o nazwie przechowywanej w 
zmiennej S. Lista Bot sL zawiera identyfikatory botów wykonujących daną taktykę zespołową. 

Dzięki akcji synchronizacji możliwa jest implementacja zachowań polegających na 
udzielaniu wsparcia innym członom drużyny. Przykładem takiego wsparcia jest sytuacja, w 
której przy wspinaniu się na drabinę pierwszy bot pilnuje na górze, a ostatni na dole. Inny 


przykład jest przedstawiony na listingu 5.20. 


Listing 5.20. Przykład użycia akcji synchronizacji — sync. 
bot_tactic(path318, [ 











mov (318), sync(pl), mov(206), ... |], assaultrifle). 
bot_tactic(path258, [ 
mov (258), sync(pl), mov(143), ... |], assaultrifle). 








Jest to fragment taktyki polegającej na równoczesnym ataku dwóch botów przez główne 
wejście w magazynie. Jeden z nich udaje się do punktu nawigacyjnego o numerze 318, a 
drugi do punktu nawigacyjnego 258. Te punkty nawigacyjne znajdują się przed wejściem po 
obu jego stronach. Ponieważ postacie mogą zaczynać rundę w różnych miejscach na planszy, 
konieczne jest upewnienie się, że znajdują się one przed wejściem przed rozpoczęciem ataku. W 
tym celu wykorzystana jest akcja synchronizacji. W momencie, gdy oba boty wykonają akcję 
sync (pl), przejdą do kolejnych akcji w taktyce zespołowej. Są to akcje ruchu do punktów 
nawigacyjnych 206 i 143, leżących wewnątrz magazynu. W ten sposób jest rozpoczynany 
równoczesny atak. Sytuacja ta została schematycznie przedstawiona na ilustracji 5.2. 

Inną akcją, specyficzną dla wykonania taktyki zespołowej, jest akcja grupowania drużyny. 
Przyjmuje ona jako parametr listę termów opisujących akcje w taktyce zespołowej (np. 
zaprezentowane we wcześniejszych przykładach mov / 1, camp/ 1, itp.). Jej wykonanie polega 
na wyborze lidera spośród botów, wykonujących akcję grupowania w obrębie tej samej taktyki 


zespołowej w tym samym momencie. Lider wykonuje akcje, których identyfikatory zostały 
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206 143 


Rysunek 5.2. Schemat sytuacji równoczesnego ataku przez wejście frontowe. 


przekazane jako parametr akcji grupowania. Pozostałe boty natomiast przemieszczają się za 
liderem i wspierają go w razie walki z przeciwnikiem. Przykład zastosowania tej akcji jest 


przedstawiony na listingu 5.21. 


Listing 5.21. Przykład użycia akcji grupowania — groupup. 
bot_tactic(path318, 
r mov(95), sync(p2), 

groupup ([camp(1), mov(101), ... J) 

], assaultrifle). 
bot _tactic(path258, 
, mov(385), sync(p2), 





groupup ([camp (1), mov(101), ... J) 
], assaultrifle). 


Zaprezentowany kod to fragment taktyki odbijania zakładników na planszy cs_assault. 
Jego celem jest spowodowanie ucieczki całej drużyny do punktu wyjścia razem z zakładnikami. 
W pewnym momencie wykonywania tej taktyki, jeden z botów udaje się do punktu 95, a drugi 
do punktu 385. Następnie boty czekają na siebie nawzajem i wykonują akcję grupowania. Jeśli 
liderem zostanie pierwszy z botów, to będzie on kampować przez jedną sekundę, a następnie 
uda się do punktu nawigacyjnego 101. Jeżeli na lidera zostanie wybrany drugi z botów to 
będzie kampować przez jedną sekundę, a następnie uda się do punktu nawigacyjnego 101 — 
tego samego co w przypadku pierwszego bota. Bot, który nie został liderem, będzie podążać za 
botem wybranym na lidera. 

Kolejną akcją, stosowaną do opisu zachowania bota w taktyce indywidualnej, jest akcja 
polegająca na powtarzaniu sekwencji akcji złożonych do momentu spełnienia pewnego 
określonego warunku. Akcja ta jest wykorzystana do patrolowania obszarów na planszy, np. 
do ochrony przed podłożeniem bomby przez terrorystów na planszy de_dust, nie została 
jednak użyta do opisu taktyk zespołowych na planszy cs_assault, a właśnie na tej planszy 


były przeprowadzane eksperymenty, których wyniki przedstawiono w rozprawie. 
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5.11. Przykłady działania botów «Bot 


W tym rozdziale zostały umieszczone dwa przykłady wnioskowania, użytego w 


implementacji botów «Bot. 


5.11.1. Przykład 1: Reakcja na komendę ,,za mną” 


Listing 5.22 przedstawia realizację wnioskowania, którego celem jest reakcja na usłyszenie 


przez bota komunikatu radiowego „za mną” (ang. „follow me”). 


Listing 5.22. Fragment kodu realizujący reakcję na komendę radiową 








game _handle message (Id, follow) :- 
bot_visible(Id, radio _caller(l!Id)), 
(l_maybe (0.5), \+tbot_following(Id, _) -> 
(N+bot_user(Id, player) -> 





























follow _bot(Id, player), 





action_follow(Id, player), 








(1 
bot_say_radio(Id, affirmative) ; 
bot_say_radio(Id, iaminposition) 
) | 


bot_say_radio(Id, negative) 








W celu uproszczenia zapisu warunku autor zastosował instrukcję „miękkiego odcięcia” 
(ang. soft cut). Jest ona deklarowana za pomocą operatorów -> i ;. Zapis 
:- Condition -> Action ; Else. oznacza, że w przypadku, gdy możliwy jest 
dowód predykatu Condition będzie przeprowadzona próba dowodu predykatu Action, a 
w przeciwnym przypadku predykatu Else. 

W kodzie na listingu 5.22 komunikat radiowy jest obsługiwany tylko w przypadku, gdy 
bot widzi nadawcę wiadomości radiowej (predykat bot_visible/2). Jeśli ten warunek 
jest spełniony to bot reaguje na komunikat radiowy. Jeśli bot nie podąża za inną postacią 
(negacja predykatu bot_following/2), to z prawdopodobieństwem 0.5 zacznie podążać 


za postacią wywołującą komunikat radiowy (predykat action_follow) i potwierdzi to 





odpowiadając komunikatem radiowym „zgoda” bot_say_radio(Id, affirmative). 


Jeśli bot już podąża za nadawcą komunikatu, to potwierdzi to odpowiednim komunikatem 








bot_say_radio(Id, iaminposition). W pozostałych przypadkach bot zareaguje 





odpowiadając komunikatem radiowym „odmawiam” bot_say_radio(Id, negative). 
Ta reguła jest przykładem reguły ogólnej dla gry Counter-Strike. Jeżeli reakcja na 
komunikat „za mną” nie zostanie zdefiniowana inaczej na poziomie typu planszy lub konkretnej 


planszy, to boty «Bot będą reagowały na ten komunikat właśnie w ten właśnie sposób. 
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5.11.2. Przykład 2: Wybór taktyki dla bota 


Przykład 5.23 przedstawia definicję wnioskowania, którego celem jest wybór taktyki dla 


bota będącego VIPem na mapie typu AS. Reguła ta funkcjonuje na wszystkich mapach typu 


AS, jest brana pod uwagę jeżeli reguły, które są zdefiniowane dla konkretnej planszy nie dają 


odpowiedzi na pytanie jak decyzja powinna być podjęta. Fragment pochodzi ze skryptu bota 


«Bot, który był użyty w celu przeprowadzenia eksperymentów opisanych w rozdziale 6. 


Listing 5.23. Fragment kodu realizujący wybór celu dla VIPa na mapie typu AS 


as_map_type_do_reasoning(I 
bot_is_vip(I 





bot _team(ld, terror) 





(first half _of _ round -> 
select_random _tactic(I 
(20, 
(10, 
select _random tactic(I 
(40, 
(20, 


(60, 
(10, 


camp_goal), 
ct_goal), 


(20, 


(20, ct_goal), 


camp_goal), 





select _random _tactic(I 





distr_pick(TacticDistr, 





select _tactic(Id, 
a, 
random _camp_wp (Wp), 
a, 


select tactic(lI 





action_camp (I 


r 


d, 


camp_goal) 


wp (Wp), 





d) 








d, [I 
t_goal 
map_goal 
d, [I 
t_goal) 








map_goal) ] 





d), 


TacticDistr) 


Tactic), 


Tactic). 





all cost(I 


d), 





do_nothing(Id)). 


Dla reguł ogólnych na poziomie typu planszy wyszczególnione są 4 taktyki, które może 


wykonywać bot: 


iść do POI drużyny terrorystów (t_goa1) — dla drużyny antyterrorystów oznacza to atak, 


iść do POI drużyny terrorystów (ct_goal) — dla drużyny antyterrorystów oznacza to 


obronę, 


kampować (camp_goal), 


realizować cel planszy (map_goal) — na mapie AS jest to ruch do strefy ucieczki. 


Bot wybiera taktykę losowo za pomocą predykatu select_random_tactic/2. 


Predykat ten przyjmuje jako parametr listę par. Każda para składa się z termu opisującego 


taktykę (np. 


ct_goal) oraz prawdopodobieństwa, wyrażonego w procentach, wyboru 


tej taktyki. Wartości prawdopodobieństwa muszą się sumować do 100%, w przeciwnym 


przypadku dowód tego predykatu spowoduje zgłoszenie wyjątku. 
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Rozkład prawdopodobieństwa wyboru taktyki zależy od tego, czy minęła pierwsza 
połowa rundy — jest to sprawdzane za pomocą predykatu first _half_of_round/0. 
W zależności od wyniku testu wywoływany jest select _random _tactic/2 z innymi 
parametrami. W przypadku dokonywania wyboru w pierwszej połowie rundy, bot będący 
VIPem wybiera najczęściej ucieczkę do strefy bezpieczeństwa. W przypadku drugiej połowy 
rundy, prawdopodobieństwa wyboru jednej z czterech opisanych taktyk przez VIPa są w 
przybliżeniu równe, z niewielką preferencją na rzecz taktyki zaatakowania przeciwnika. 

Wybór identyfikatora taktyki z zadanym  prawdopodobieristwem realizuje 


predykat distr_pick/2, natomiast realizację taktyki o zadanym identyfikatorze 





— select_tactic/2. W przykładzie pokazano realizację taktyki o identyfikatorze 
camp_goal. Jest to taktyka polegająca na kampowaniu. Jej realizacja polega na wyborze 
losowego punktu, który zawiera adnotację o możliwość kampowania (random_camp_wp/1) 
i wykonania akcji kampowania z celem będącym tym punktem (action_camp/2). Kod 


realizujący tę taktykę przedstawiono na listingu 5.24. 


Listing 5.24. Fragment kodu losujący punkt do kampowania 


anywp_camp (Ret) :- 
wp_def (Wp, data (flags ( porate) _)) + 
Ret = Wp. 





random_camp (Wp) :- 
findall (Wp, anywp_camp (Wp), LWp), 
l_random member (LWp, Wp). 


Predykat anywp_camp/ 1 uzgadnia zmienną Wp z identyfikatorem punktu nawigacyjnego, 
który jest oznaczony jako punkt do kampowania. Oznaczenie to jest realizowane 
jako wystąpienie wartości 1 jako pewnego podtermu w termie flags. Predykat 
random_camp/1 znajduje wszystkie identyfikatory punktów nawigacyjnych, dla których 
predykat anywp_camp/1 jest prawdziwy. Następnie ze znalezionego zbioru wybierany jest 


losowy element. 


5.12. Podsumowanie 


Funkcje wnioskowania deliberatywnego i reaktywnego w przypadku botów kBot działają w 
oparciu o wnioskowanie w logice. Łączą one fakty uzyskane z obserwacji oraz fakty powstałe z 
wewnętrznego stanu bota w celu podjęcia decyzji o akcji, która będzie wykonywana. Regułowy 
opis wnioskowania można rozumieć jako wiedzę, jak grać w daną grę i jak wykorzystywać 


dostępne informacje oraz własne cechy intelektualne”: pamięć, zmysły, emocje itp. Gracz 


2 w przypadku człowieka najczęściej nie jest to typ wiedzy deklaratywnej 
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uzyskuje tego typu wiedze poprzez granie w gre, rozmowy z innymi graczami, ogladanie 
meczów, czytanie poradników itp., natomiast w przypadku botów, rolę tej wiedzy pełnią 
reguły, które nie zmieniają się w trakcie rozgrywki i są dostarczane przez eksperta (najczęściej 
programistę bota) podczas programowania botów. Każdy z trzech powyższych komponentów, 
tj. informacje o Świecie, informacje dostarczanych przez odpowiednik procesów poznawczych 
i wiedzę o sposobie postępowania w grze, można opisać za pomocą programowania w logice, 
co czyni z niego wygodne narzędzie w przypadku programowania zachowania botów w grze 


Counter-Strike. 


6. Eksperymenty 


Ten rozdział jest poświęcony opisowi eksperymentów, które zostały przeprowadzone w 
celu weryfikacji tezy rozprawy. Miały one na celu sprawdzenie, że zastosowanie metodyki 
tworzenia botów polegającej na organizacji reguł postępowania bota w grupy o różnych 
stopniach ogólności prowadzi do podniesienia komfortu rozgrywki. Pokazane są również 
eksperymenty dotyczące wydajności w celu pokazania, że przedstawiona metodyka ma 


praktyczne zastosowanie. 


6.1. Aspekty praktyczne związane z przeprowadzeniem eksperymentów 


W ramach rozprawy zostały przeprowadzone eksperymenty polegające na badaniu wpływu 
specjalizacji zachowania botów do konkretnej planszy na odczucia graczy. Wpływ ten 
zweryfikowano poprzez analizę zachowań graczy oraz ankiet przez nich wypełnionych na 
podstawie gry przeciwko botom «Bot. Dane te zebrano dzięki umożliwieniu gry online na 
publicznych serwerach. 

Boty «Bot i boty E[POD] mają wspólne akcje złożone, tj. ten sam kod źródłowy definiuje 
akcje złożone u obu typów botów. Boty kBot podejmują decyzje w oparciu o reguły o 
różnym stopniu ogólności. Ogólne reguły i reguły dla typów planszy zostały skopiowane ze 
sterownika botów E/POD]J, dlatego boty kBot bez zdefiniowanych reguł specyficznych dla 
planszy podejmują dokładnie takie same decyzje jak boty E/POD]. 


Charakterystyka planszy użytej w eksperymentach 


Eksperymenty z graczami były prowadzone na planszy cs_assault. Jest to plansza, dla 
której postacie są podzielone na dwie drużyny — terrorystów i antyterrorystów. Scenografią 
planszy jest dzielnica przemysłowa w mieście. Zadaniem drużyny antyterrorystów jest 
uwolnienie zakładników w czasie trwania rundy. Terroryści przetrzymują zakładników w 
magazynie otoczonym przez wysokie budynki 1 ich zadaniem jest niedopuszczenie do odbicia 
zakładników przez antyterrorystów w wyznaczonym czasie. Przykładowe widoki planszy 
zostały przedstawione na ilustracjach 6.1 oraz 6.2, zaś poglądowy plan planszy znajduje się 
na ilustracji 6.3. 

Na tej planszy drużyna terrorystów jest drużyną defensywną, a antyterrorystów — 


ofensywną. Jest to mała plansza o nieskomplikowanym układzie przestrzennym. Dostępna 
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Rysunek 6.1. Widok na zewnątrz magazynu Rysunek 6.2. Widok wewnątrz magazynu 


tylne drzwi 


podwieszany 
~ chodnik 


NEB by 


wentylacyjne 
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BZ 
chodnik 
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frontowe 





CT Strefa rozpoczęcia gry przez drużynę antyterrorystów. 
T Strefa rozpoczęcia gry przez drużynę terrorystów. 
H Pomieszczenie z zakładnikami. 


Rysunek 6.3. Poglądowy plan planszy cs_assault. 


jest ona we wszystkich dystrybucjach gry Counter-Strike, i z tego powodu jest znana niemal 


wszystkim graczom tej gry. 


Ogólne reguły działania botów «Bot na planszy cs_assault 


Reguły postępowania botów «Bot na planszach typu CS, dla których nie ma zdefiniowanych 
reguł specyficznych dla danej planszy, powodują wybór jednego z czterech dostępnych działań: 
camp_goal, ct_goal, t_goal oraz map_goal. Działania te zostały omówione w 
rozdziale 5.11 jako przykład działania wnioskowania bota. Kod realizujący wybór działania 


na planszy typu CS jest zaprezentowany na listingu 6.1. 
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Listing 6.1. Deklaracja reguł działania botów na planszy typu CS. 


/* CS (counter-strike) - specific map reasoning */ 





cs_map_type_do_reasoning(Id) :- 





bot _team(ld, terror), 
(first _ half of round -> 
select _random _tactic(I 








(40, camp_goal), (40 
(10, ct_goal), (10, 
select _random tactic(I 





(20, camp_goal), (40 
(20, ct _goal), (20, 





cs_map_type_do_reasoning(I 








d, I 
, t_goal), 


map_goal)]) ; 


d, [ 
, t_goal) 





map_goal) ]) 


a). = 





bot_team(Id, counter), bot _has_hostages (Id), 





goto_rescue_zone (Id). 





cs_map_type_do_reasoning(I 
bot_team(Id, counter), \ 
(first_half of round => 
select_random_tactic(I 











(60, map_goal), (20, 


d) -= 
+bot_has_hostages (Id), 





d, [ 
ct_goal), 


(10, t_goal), (10, camp_goal)]) ; 





select _random _tactic(I 


(20, map_goal), (65, 


a, I 





ct_goal) 


(10, t_goal), (5, camp_goal)]) 


W liniach 2-11 jest zdefiniowana reguła dla drużyny terrorystów, w której cztery 
wspomniane działania są wybierane z rozkładem prawdopodobieństwa zależnym od tego, 
czy upłynęła pierwsza połowa rundy (predykat first _half_of_round). Jeśli nie 
upłynęła pierwsza połowa to boty w drużynie terrorystów preferują działania defensywne, tj. 
kampowanie (camp_goal) i ochronę strategicznych punktów dla swojej drużyny (t_goal). 


Natomiast po upłynięciu pierwszej połowy rundy, boty w drużynie terrorystów zwiększają 





preferencje atakowania przeciwnika (ct_goal) i pilnowania zakładników (map_goal), 
kosztem rzadszego wyboru kampowania. 

Dwie pozostałe reguły (linie 13-25) opisują działania botów z drużyny antyterrorystów. 
Reguła zdefiniowana w liniach 13-15 mówi o tym, że bot, który prowadzi zakładników, 
powinien udać się do punktu ewakuacji. Natomiast reguła w liniach 17-26 definiuje wybór 
działania dla pozostałych botów w drużynie. Jeżeli nie minęła pierwsza połowa rundy, to 


preferuje się wybór realizacji celu planszy, tj. udania się do pomieszczenia, gdzie terroryści 
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przetrzymują zakładników (map_goal) oraz, w mniejszym stopniu, udanie się do miejsca, z 
którego można eliminować terrorystów ct_goal. Po upłynięciu pierwszej połowy rundy boty 
preferują eliminowanie terrorystów oraz, w mniejszym stopniu, realizację celu planszy. Przez 
cały czas trwania rundy bot ma małe szanse na wybór działania polegającego na kampowaniu 
(camp_goal) oraz ochronie innych postaci (t_goal). Dzieje się tak, ponieważ na mapach 


typu CS drużyna antyterrorystów jest drużyną ofensywną. 


Specjalizacja zachowania botów kBot dla środowiska eksperymentów 


W ramach eksperymentów zostały zaimplementowane następujące taktyki drużynowe dla 

drużyny antyterrorystów: 

1. wejście frontem, przejście przez hall, dalej do zakładników, uwolnienie ich i ucieczka; 

2. wejście przez szyb wentylacyjny, uwolnienie zakładników i ucieczka frontem; 

3. wejście tylnymi drzwiami, wdrapanie się na podwieszane chodniki, tam próba zastrzelenia 
terrorystów, a następnie przejścia do pokoju z zakładnikami. 

Taktyki te zostały schematycznie przedstawione na rysunku 6.4. Taktyki drużyny terrorystów 

polegają na przygotowaniu zasadzki na drużynę przeciwną: 

1. przy tylnych drzwiach, jeden bot z pistoletem maszynowym i jeden bot z karabinem 
snajperskim; 

2. przy wejściu frontowym, uzbrojeni w pistolety maszynowe i jeden bot z karabinem 
snajperskim; 

w pokoju z zakładnikami uzbrojeni w pistolety maszynowe; 

4. na podwieszanych chodnikach uzbrojeni w karabiny snajperskie; 

na podwyższonym przejściu do pomieszczenia z zakładnikami uzbrojeni w karabiny 

snajperskie. 

Zostały one schematycznie przedstawione na rysunku 6.5. 

Przestawione taktyki są zaimplementowane z użyciem szablonów przedstawionych w 
rozdziale 5.10.1. Reguły te funkcjonują razem z regułami przedstawionymi na listingu 6.1. Bot 
w pierwszej kolejności stara się stworzyć zespół i postępować według taktyki zespołowej. W 
przypadku braku powodzenia w budowaniu zespołu bot postępuje zgodnie z ogólnymi zasadami 


prowadzenia rozgrywki dla danego typu planszy. 


Rozlokowanie eksperymentów online 


Strona internetowa z informacjami na temat botów «Bot oraz przeprowadzonych z nim 
eksperymentów funkcjonuje pod adresem http: //www.kappalabs.org. 

Środowisko eksperymentów uruchomiono online na serwerach chmury obliczeniowej 
Amazon EC2. Zastosowanie chmury obliczeniowej było ważną właściwością Środowiska 
testowego, ponieważ pozwoliło na lokowanie instancji serwerów testowych w centrach 


obliczeniowych w różnych lokalizacjach geograficznych. Takie rozwiązanie zmniejszyło 
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Rysunek 6.4. Taktyki drużynowe dla antyterrorystów 





Rysunek 6.5. Taktyki drużynowe dla terrorystów 


opóźnienia sieciowe graczy na serwerach, ponieważ mogli wybierać serwery ulokowane 


najbliżej miejsca, w którym się znajdowali. 


6.2. Wyniki eksperymentów 


W ramach pracy przeprowadzone zostały trzy typy eksperymentów: 


1. eksperymenty dotyczące wydajności implementacji botów k.Bot, 
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serwery k-Labs 
centra obliczeniowe Amazon EC2 











Rysunek 6.6. Wdrożenie serwerów testowych w dostępnych centrach obliczeniowych Amazon EC2. 


2. eksperymenty dotyczące wyników gry botów «Bot z botami E/POD], 
3. eksperymenty dotyczące zaangażowania graczy w grę z botami «Bot. 

Eksperymenty wymienione w punkcie 1. i 2. stanowią praktyczną weryfikację decyzji 
projektowych i technik implementacyjnych botów «Bot. Były one wykonywane przy każdej 
nowej wersji botów «Bot. W sytuacji, gdy boty nie spełniały wymagań dotyczących wydajności 
działania lub skuteczności rozgrywki, poprawiano implementację. 

Eksperymenty wymienione w punkcie 3. 1 omówione w podrozdziale 6.4 miały na celu 
wykazanie tezy pracy. Były one bardzo czasochłonne do przeprowadzenia, dlatego wykonano 


je w momencie, gdy rezultaty pozostałych eksperymentów były zadowalające. 


6.2.1. Wydajność implementacji botów «Bot 


Podczas prac nad implementacją botów «Bot wydajność była mierzona przez testy, 
przeprowadzane za pomocą stworzonego w tym celu oprogramowania do zbierania statystyk 
o szybkości działania poszczególnych elementów sterownika botów. Celem było uzyskanie 
implementacji, w której możliwe by było takie zdefiniowanie wnioskowania botów, aby 
realizowały one cele planszy, zaś czas działania! mechanizmów wnioskowania botów 
stanowiłby nie więcej niż 2.5% czasu działania sterownika botów. 

Gra z botami «Bot oraz E[POD] była możliwa dla graczy dzięki uruchomianiu botów na 
publicznych serwerach. Wydajność botów «Bot porównano z wydajnością botów E/POD] 
poprzez pomiar obciążenia procesora na dwóch serwerach EC2 klasy „mikro” w tym samym 
centrum obliczeniowym. Pomiary obciążenia procesora serwerów są zbierane przez firmę 
Amazon dla ich klientów korzystających z każdego rodzaju serwerów. Dane te zazwyczaj się 
wykorzystywane w celu monitorowania działania oprogramowania działającego na serwerach. 


W badaniu botów «Bot użyto właśnie takich danych. 


' miara ta jest dobrze określona, ponieważ sterownik botów działa w jednym wątku 
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Na każdym z serwerów było 8 botów «Bot (po 4 na drużynę). Rozgrywka była podzielona 
na 30-minutowe mecze na planszy cs_assault. Boty kBot wykorzystywały taktykę opisaną 
w rozdziale 6.1. Pomiary wydajności przeprowadzano przez tydzień, podczas którego boty 
działały na serwerze. 

Wykres 6.7 przedstawia przykładowe przebiegi czasowe obciążenia procesora dla serwera, 
na którym działały boty kBot, oraz serwera, na którym działały boty E/POD]. Widoczny na 
przykładowych przebiegach nagły wzrost obciążenia około 60 minuty jest spowodowany przez 
gracza, który gra najpierw na jednym, a następnie na drugim serwerze. Na obu serwerach 
nie ma innych graczy poza tym jednym. Pojedynczy gracz korzystający z serwera powoduje 
obciążenie procesora na poziomie 80%. Przy dwóch lub więcej graczach obciążenie procesora 
wynosi 100% i występują problemy z płynnym funkcjonowaniem rozgrywki. Z tego powodu 
serwery EC2 typu „mikro” były wystarczające do przeprowadzenia eksperymentów wyłącznie 


z pojedynczym graczem. 
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Rysunek 6.7. Fragment wykresu obciążenia procesora w czasie dla serwerów, na których działały boty 
E[POD] i «Bot. 


Wykres 6.8 przedstawia rozkład obserwowanego obciążenia procesora na serwerach w 
momentach, gdy nie było na nich żadnych graczy. Obciążenie procesora dla serwera z 
botami «Bot było Średnio 7.10% wyższe niż w przypadku botów E/POD]. Wykres 6.9 
przedstawia rozkład obciążenia procesora w momentach, gdy z serwera korzystał pojedynczy 
gracz. W takim przypadku różnica między botami kBot i E[POD] wynosiła 4.48%. Wzrost 


ten można przypisać zmianie sposobu podejmowania decyzji wysokopoziomowych poprzez 
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wprowadzenie warstwy wnioskowania opartej na regutach opisanych w jezyku Prolog. Inne 
różnice w obciążeniach procesora w przypadku serwera z graczami i bez graczy wynikają z 
wielowątkowości aplikacji. Obsługa gracza zdalnego wymaga obsługi połączenia sieciowego, 
które jest obsługiwane przez osobny wątek. Podwyższona aktywność tego wątku wpływa na 


sposób przetwarzania danych na innych wątkach. 


6.2.2. Wyniki gry botów «Bot przeciwko botom E/POD] 


Testy, w których boty «Bot i E[POD] grały przeciwko sobie, miały na celu wstępną 
weryfikację efektywności działania botów «Bot. Testy były przeprowadzane na lokalnym 
komputerze i polegały na przeprowadzeniu 10 meczy po 10 minut w 4 konfiguracjach: 

— drużyna antyterrorystów (AT) złożona z botów «Bot, a terrorystów (T) z botów E/POD], 
— drużyna antyterrorystów (AT) złożona z botów E/POD], a terrorystów (T) z botów «Bot, 
— obie drużyny złożone z botów «Bot, 

— obie drużyny złożone z botów E/POD]. 

Każdy mecz mógł się składać z różnej liczby rund, w zależności od tego, w jaki sposób 
boty prowadziły rozgrywkę. Limit górny czasu pojedynczej rundy wynosił 2 minuty, więc 
mecz składał się co najmniej z pięciu rund. Runda mogła skończyć się wcześniej wskutek 
zwycięstwa jednej z drużyn. Jako zwycięstwo uznawano eliminację jednej drużyny przez drugą 
lub realizację przez jedną z drużyn celu planszy, co powodowało, że w ramach 10-minutowego 
limitu mogło się odbyć więcej niż 5 rund gry. 

Rozgrywki były prowadzone na planszy cs_assault, której cele były określone 
następująco: 

— dla antyterrorystów — zaprowadzenie zakładników do strefy bezpieczeństwa, 
— dla terrorystów — niedopuszczenie do ratunku zakładników. 
Boty kBot używały taktyk zespołowych opisanych w rozdziale 6.1. 

Podczas eksperymentów była odnotowywana liczba zwycięstw każdej z drużyn — wyniki 
tych pomiarów znajdują się w tabeli 6.1. Odnotowywana również była liczba przypadków 
tych zwycięstw, które nie polegały na eliminacji drużyny przeciwnej. Wyniki pomiarów 
przedstawiono w tabeli 6.2. 

Z, uwagi na zmienną liczbę rund w meczu obliczano również średnią długość pojedynczej 
rundy w każdej konfiguracji oraz średnią liczbę rund przeprowadzonych w ramach 
10-minutowego meczu. Wyniki przedstawione są w tabeli 6.3. 

Wyniki przeprowadzonych eksperymentów wyraźnie wskazują na przewagę botów «Bot 
nad botami E/POD]. W każdym przypadku, gdy drużyna złożona z botów E/POD] została 
zastąpiona drużyną złożoną z botów «Bot, można było zaobserwować wzrost liczby zwycięstw 


tej drużyny. 
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Rysunek 6.8. Histogram obciążenia procesora, bez graczy zdalnych na serwerze. 
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Rysunek 6.9. Histogram obciążenia procesora, z pojedyńczym graczem zdalnym na serwerze. 


W konfiguracjach, w których obie drużyny były złożone z tego samego typu botów 
(E[POD] lub kBot), drużyna terrorystów odnosiła większą liczbę zwycięstw niż drużyna 


antyterrorystów. Może być to wytłumaczone faktem, że rozgrywka na planszy cs_assault 
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boty AT | boty T | zwycięstwa AT | zwycięstwa T 

E[POD] | E[POD] 4.1 6.4 
kBot | E[POD] 8.0 4.5 

E[POD] | «Bot 1.5 7.0 
KkBot KkBot 6.0 7.8 





Tablica 6.1. Srednia liczba zwycięstw przypadających na drużynę podczas meczu. 




















boty AT | boty T | zwycięstwa AT | zwycięstwa T 

E[POD] | E[POD] 0.4 1.2 
kBot E[POD] 3.6 0.5 

E[POD] | kBot 0.2 2.5 
kBot kBot 1.1 0.1 











Tablica 6.2. Średnia liczba zwycięstw bez eliminacji przeciwnej drużyny w ciągu meczu. 




















boty AT | boty T | czasrundy [s] | liczba rozegranych rund 
E[POD] | E[POD] 70 10.5 

kBot | E[POD] 52 12.5 
E[POD] | «Bot 85 8.5 

KkBot KBot 48 13.8 








Tablica 6.3. Średni czas trwania rundy i średnia liczba rund podczas meczu. 


nie jest zrównoważona. Według zebranych opinii graczy plansza daje przewagę drużynie 
terrorystów. 

Można zauważyć, że w przypadku drużyny antyterrorystów, złożonej z botów kBot, rundy 
były krótsze i przeprowadzono ich więcej w ramach jednego meczu. Można to interpretować 
jako bardziej agresywne działanie tej drużyny. Analizując liczbę przypadków zwycięstw 
drużyny antyterrorystów, niepolegających na eliminacji drużyny przeciwnej, można zauważyć 
większą liczbę takich zwycięstw w przypadku drużyny złożonej z botów kBot. To również 
świadczy o większej agresywności i lepszym ukierunkowaniu na cel stylu gry drużyny z botami 


k.Bot. 


6.2.3. Badanie zachowania graczy w grze online 


Kolejny typ eksperymentów służył badaniu zaangażowania graczy. Polegał on na 
rejestrowaniu czasu aktywnego uczestnictwa gracza w rozgrywce przy różnych rodzajach 
botów oraz zliczaniu liczby wizyt graczy na serwerze. Jedynymi formami zaangażowania 
gracza był sam fakt uczestnictwa w rozgrywce oraz czas gry. Podczas gry na serwerach gracze 
nie wiedzieli, że biorą udział w eksperymentach. Graczom nie udzielano informacji na temat 


funkcjonujących na serwerze botów. Eksperyment ten został wykonany po eksperymentach 
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opisanych w rozdziale ?? oraz 6.2.2. Gracze testowali wersję botów «Bot, która spełniała 
przyjęte kryteria odnośnie wydajności oraz efektywności rozgrywki. 

Badania uwzględniały testowanie Counter-Strike w wersji 1.5 za pośrednictwem sieci WON 
oraz Counter-Strike w wersji 1.6 za pośrednictwem Steam. W obu przypadkach wykorzystano 
również zewnętrzne serwisy, zbierające informacje o aktywnych serwerach gry Counter-Strike. 
Sieci WON i Steam oraz wspomniane serwisy były wykorzystane w celu informowania graczy 
o możliwości gry na serwerze. 

Wersje serwera z grą Counter-Strike 1.5 i 1.6 były uruchomione jednocześnie na serwerach 
EC2, a dane były zbierane przez 7 dni. Eksperymenty były przeprowadzane na planszy 
cs_assault. Testowano następujące konfiguracje: 

1. bez botów — na serwerze nie było żadnych botów; 
2. z botami E/POD] — na serwerze działały dwie drużyny z 4 botami E/POD]; 
3. z botami «Bot — na serwerze działały dwie drużyny z 4 botami «Bot, 

W przypadku dołączenia się do gry człowieka, jego postać zastępowała pewnego bota w 
drużynie, do której dołączał gracz. W ten sposób przez cały czas rozgrywki na planszy było 8 
postaci — po 4 w każdej drużynie. Przy przystępowaniu człowieka do gry mecz był resetowany, 
tj. zaczynał się on od nowa. 


Wyniki dotyczące zebranych parametrów sesji graczy przedstawiono w tabelach 6.5, 6.4 








oraz 6.7. 
CS 1.5 | CS 1.6 
bez botów 23 25 
boty E/POD] 25 123 
boty «Bot 24 205 

















Tablica 6.4. Liczba wizyt graczy na serwerach z różnymi konfiguracjami. 








CS 1.5 | CS 1.6 
bez botów 103 s 75 s 
boty E[POD] | 232s | 233s 
boty «Bot 275s | 383s 

















Tablica 6.5. Sredni czas uczestnictwa gracza w rozgrywce na różnych konfiguracjach serwera. 




















CS 1.5 | CS 1.6 
bez botów 3 0 
boty E[POD] 3 9 
boty kBot 2 16 





Tablica 6.6. Rozgrywki z dwoma lub więcej graczami online. 
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Rysunek 6.10. Histogram długości trwania sesji gracza. 


Sama obecność jakichkolwiek botów w grze przyczynia się do podniesienia średniego 
zaangażowania graczy. Dowodzi tego wydłużenie średniego czasu uczestnictwa w rozgrywce 
w stosunku do ,,pustego” serwera. Interesujacym faktem jest zwiększenie liczby wizyt na 
serwerze w przypadku wprowadzenia do gry botów dla wersji Counter-Strike 1.6 oraz brak 
podobnego efektu w przypadku wersji 1.5. Można to wytłumaczyć faktem, że w starszej wersji 
gry, podczas wybierania przez gracza serwera do rozgrywki, serwer bez botów i serwer z botami 
są przedstawione tak samo w interfejsie gry. Starsza wersja gry nie informuje gracza o fakcie, 
że na serwerze działają boty. Udzielane są informacje wyłącznie o graczach. W nowszej 
wersji (1.6), interfejs graficzny wyświetla również informacje o działających botach podczas 


wybierania serwera, z którym gracz chce się połączyć. 
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Rysunek 6.11. Dystrybuanty empiryczne długości trwania sesji gracza. 


Na rysunkach 6.10 i 6.11 przedstawione zostały histogramy oraz wykresy dystrybuanty 
empirycznej czasu trwania rozgrywki graczy, zaobserwowanych dla botów E/POD] i kBot. 

Z obu rysunków wynika, że obecność botów «Bot zwiększa średnie zaangażowanie graczy 
w porównaniu do obecności botów E/POD]. Objawia się to zarówno wydłużeniem czasu 
rozgrywki jak i zwiększeniem liczby wizyt na serwerach. Można zauważyć, że w przypadku 
botów «Bot wielu graczy spędziło znacznie więcej czasu (do 600 sekund) niż wynosi mediana 
dla obu typów botów (ok. 300 sekund). Silnie skupienie czasu gry wokół wartości 10 minut 
jest spowodowane faktem, że po dołączeniu gracza mecz zaczynał się od nowa i trwał ok. 
10 minut. Czas ten mógł być przekroczony z uwagi na dokończenie ostatniej rundy, dlatego 


też odnotowywano wiele pomiarów nieznacznie przekraczających 10 minut. Nie odnotowano 
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natomiast pomiarów znacznie przekraczających 10 minut, można więc sądzić, ze gracze nigdy 
nie decydowali się na rozegranie kolejnego meczu. 

Porównując zachowanie graczy grających z botami E/POD] i kBot można zauważyć, że 
użytkownicy tych pierwszych szybko się zniechęcali rozgrywką i niewielu z nich kończyło 
mecz w pełni. Ten fakt Świadczy na korzyść botów «Bot, ale nie pozwala na pełne poznanie 
przyczyn tego zjawiska. Można się ich doszukiwać zarówno w bardziej realistycznej rozgrywce 
botów, jak też w tym, że sposób prowadzenia rozgrywki przez boty jest mało rozpowszechniony. 
Lepsze poznanie przyczyn większej atrakcyjności botów «Bot jest możliwe dzięki analizie 


wyników przedstawionych w kolejnym rozdziale. 


6.3. Badanie opinii graczy 


Opinie graczy są narzędziem badania ich zaangażowania. W badaniach prezentowanych w 
rozprawie opinie graczy zostały zebrane za pomocą ankiet. 

Eksperymenty, w których człowiek grał przeciw botom, zostały przeprowadzone na planszy 
cs_assault. Eksperymenty te polegały na dwukrotnym umieszczaniu gracza w jednej, 
wybranej przez niego drużynie: 

1. raz na serwerze, na którym działały boty «Bot ze specjalizacją dla planszy cs_assault 
opisanej w rozdziale 6.1 (nazwa serwera — Intrepid); 
2. raz na serwerze, na którym działały boty E/POD] bez żadnych modyfikacji (nazwa serwera 

— Nevada). 

Kolejność wyboru serwerów nie była sprecyzowana — gracze rozpoczynali eksperyment 
od dowolnego z nich. Gracze nie wiedzieli, które boty działają na każdym z serwerów. 
Ponieważ w czasie eksperymentów opisanych w rozdziale 6.4 zaobserwowano znacznie 
większe zaangażowanie graczy w wersji gry Counter-Strike 1.6 niż w wersję 1.5, eksperyment 
opisany w tym punkcie był przeprowadzany wyłącznie w wersji gry 1.6. 

Następnie gracze byli proszeni o wypełnienie porównawczej ankiety zawierającej pytania 

na temat obydwu serwerów: 

1. na którym serwerze rozgrywka była bardziej przyjemna? 

2. na którym serwerze poziom rozgrywki był trudniejszy? 

3. na którym serwerze boty funkcjonowały bardziej realistycznie? 

Na każde z pytań gracze mogli udzielić następujących odpowiedzi: "Zdecydowanie 
Intrepid”, "Raczej Intrepid”, "Trudno powiedzieć”, "Raczej Nevada”, "Zdecydowanie Nevada”. 
Dodatkowo, gracze mogli pozostawić dowolne komentarze, które były również źródłem 
wartościowych informacji (np. sugestie o tym, że plansza cs_assault nie daje równych 


szans obu drużynom). 
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Udział w eksperymencie wymagał od gracza poświęcenia dużej ilości czasu (ok. 30 minut). 
Z, tego powodu badania nie cieszyły się dużą popularnością, mimo aktywnej formy ich reklamy 
(kontakt ze społecznościami skupiającymi graczy Counter-Strike, reklama w systemie AdWords 
i na portalu Facebook). Możliwe jednak było uzyskanie ok. 40 wiarygodnych wyników. 
Rezultaty ankiet zostały przedstawione na ilustracjach 6.12, 6.13 oraz 6.14. 


Zdecydowanie Intrepid 


Raczej Intrepid 
nee 37.5 


9.375 


Trudno powiedzieć 6.25 






Raczej Nevada 
Zdecydowanie Nevada 


Rysunek 6.12. Rozkład odpowiedzi na pytanie: ,,Na którym serwerze rozgrywka była bardziej 
przyjemna?” 
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Rysunek 6.13. Rozkład odpowiedzi na pytanie: „Na którym serwerze poziom rozgrywki był 
trudniejszy?” 


Odpowiedzi uzyskane na pytanie „na którym serwerze rozgrywka była bardziej 
przyjemna?” (wykres 6.12) wskazują na brak znaczącej poprawy uśrednionej satysfakcji z gry 
botami «Bot w stosunku do gry z botami E/POD]. Jednakże, gdyby oba typy botów oferowały 
graczowi ten sam typ rozgrywki, należałoby się spodziewać, że gracze wybieraliby częściej 
odpowiedź „Trudno powiedzieć”. Zaobserwowano jednak dużo odpowiedzi mówiących, że 
gra z botami kBot jest zdecydowanie przyjemniejsza oraz dużo odpowiedzi mówiących, że 


gra z botami E/POD] jest zdecydowanie przyjemniejsza. Można więc wnioskować, ze 
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Zdecydowanie Intrepid 


46.875 


Raczej Intrepid 9375 


25 Zdecydowanie Nevada 





Trudno żówieda5 1 NORA 


Rysunek 6.14. Rozkład odpowiedzi na pytanie: „Na którym serwerze boty funkcjonowały bardziej 
realistycznie?” 


boty «Bot dostarczają innej rozrywki niż boty E/POD]. Wyniki obrazowane ilustracjami 
6.13 i 6.14 mówią więcej na temat oferowanego typu rozrywki. Można zauważyć, że 
boty «Bot były uważane za trudniejszych przeciwników i ich zachowanie było uważane 
za bardziej realistyczne. Odczucie większego poziomu trudności gry z botem jest zgodnie 
z zaobserwowanym w rozdziale 6.2.2 ukierunkowaniem na celu gry oraz zwiększoną 
skutecznością rozgrywki w stosunku do bota E/POD]. 

Należy podkreślić, że różnice w odczuciach graczy związanych z grą z botami «Bot 
i E[POD] można przypisać wyłącznie różnicom w algorytmie podejmowania decyzji 
wysokopoziomowych przez te boty, gdyż warstwa wykonawcza bota «Bot i E[POD] 
wykorzystywała te same akcje złożone (rozdziały 2.1, 4.3 oraz 5.6), a boty różniły się jedynie 
sposobem podejmowania decyzji wysokopoziomowych, które były specjalizowane do planszy 
dla «Bot i ogólne dla E[POD]. 

W opiniach graczy pojawiały się podobne uwagi dotyczące mechaniki niskopoziomowej dla 
obu botów (np. sposób, w jaki celują i się poruszają). Jednocześnie gracze dostrzegali różnice 
w mechanice wysokopoziomowej (np. dokąd boty się przemieszczają, w którym momencie 
atakują, jaką broń wybierają). 

Na podstawie przedstawionych wyników można wnioskować, że zmiany w algorytmie 
podejmowania decyzji złożonych wpływają na postrzeganie przez graczy sposobu prowadzenia 
rozgrywki przez boty. W przypadku botów kBot zmiany w tym algorytmie mają na celu 
uwzględnianie specyficznych cech plansz, co prowadzi do postrzegania przez graczy stylu 
gry tych botów jako bardziej realistycznego i trudniejszego niż w przypadku botów, które nie 


uwzględnia takich cech planszy. 
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6.4. Badanie zachowania graczy w grze online w różnych lokalizacjach 


geograficznych 


Kolejnym krokiem w zbieraniu statystyk dotyczących grania online było uruchomienie gry 
na serwerach w centrach obliczeniowych rozlokowanych w różnych regionach geograficznych 
(rys. 6.6). Celem tych eksperymentów było sprawdzenie, czy Średni czas sesji gry ulegnie 
zmianie, gdy boty zostaną uruchomione w centrum obliczeniowym ulokowanym w innym 
miejscu. 

W przypadku eksperymentów uruchomiono w każdej ze stref instancje serwera z grą 
w wersji 1.6 z botami «Bot i obserwowano liczbę graczy z poszczególnych rejonów 
geograficznych. Uzyskane wyniki zostały przestawione w tabelach 6.7 i 6.8 oraz na wykresie 
6.15. 





Ameryka | Azja | Europa 
1 instancja 215 — 
3 instancje 212 509 337 























Tablica 6.7. Rozkład liczby graczy w zależności od liczby uruchomionych instancji. 





Ameryka | Azja | Europa 
1 instancja 372 s — — 
3 instancje 366 s 351s | 377s 























Tablica 6.8. Średni czas sesji gracza w zależności od liczby uruchomionych instancji. 


Uruchomianie dodatkowych instancji pozwoliło na zwiększenie całkowitej liczby graczy, 
którzy grali z botami kBot. Świadczy to o tym, że istotnym czynnikiem wpływającym 
na dołączenie gracza do gry jest opóźnienie sieciowe, przekładające się na opóźniania w 
grze. Ciekawym wynikiem jest zaobserwowanie zwiększonego zainteresowania grą w regionie 
azjatyckim. 

Wykresy na rysunku 6.15 pokazują podobne zachowanie graczy, jak przypadku badań 
z rozdziału 6.4. Podobieństwo to polega na tym, że ok. 40% graczy rozgrywa mecz do 
końca, pozostali rezygnują z gry w przybliżeniu równomiernie podczas trwania meczu. To 
podobieństwo może stanowić przesłankę do wniosku, że przynajmniej w pewnym stopniu 


interakcja z botami «Bot jest niezależna od regionu geograficznego. 


6.5. Podsumowanie 


Przedstawione w tym rozdziale eksperymenty i ich wyniki wskazują, że cel pracy 


został osiągnięty. Stosując przedstawioną w rozprawie metodykę możliwe jest zwiększenie 
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zaangażowania graczy poprzez tworzenie bardziej realistycznych zachowań botów. W 
przypadku botów kBot ich zachowanie jest definiowane poprzez reguły opisujące sposób 
wykorzystania specyficznych właściwości planszy. Bez tych reguł boty grają stosując ogólne 
zasady, które umożliwiają im działanie, jednak takie zachowanie jest uważane za mniej 
realistyczne. 

Badania wydajności botów i sam fakt przeprowadzenia publicznych badań wskazują, że 
oprogramowanie będące przedmiotem tej pracy może być stosowane na serwerach gier online. 
Zostało więc zachowane założenie projektowe o stworzeniu rozwiązania, które będzie mogło 


działać w prawdziwym środowisku gier sieciowych. 
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Rysunek 6.15. Dystrybuanta empiryczna trwania sesji gracza na serwerach w różnych rejonach 
geograficznych. 
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7. Podsumowanie pracy 


W pracy pokazano, ze specjalizacja zachowania botów, uwzględniająca warunki konkretnej 
planszy, prowadzi do zwiększenia zaangażowania graczy w grę na tej planszy i poprawia u nich 
wrażania realizmu rozgrywki. Przeprowadzono przykładową specjalizację botów dla planszy 
cs_assault i porównano wersje botów ze specjalizacją (KBot) z wersja bez specjalizacji 
(E[POD]). 

Specjalizacja zachowania jest jednym ze sposobów wykorzystania sposobu wnioskowania 
bota opartego na wykorzystaniu reguł decyzyjnych zorganizowanych w grupy o różnym stopniu 
ogólności. Udane wykorzystanie architektury bota kBot, będącej przedmiotem rozprawy, 
Świadczy o jej pozytywnym wpływie na projektowanie botów. 

Specjalizacja zastosowana w pracy jest jedną z wielu możliwych sposobów na specjalizację 
zachowania botów na planszy cs_assault. Jednak pozytywny rezultat jej zastosowania 
świadczy o tym, że specjalizacje takie są w stanie zwiększać zaangażowanie graczy. Do 
uzyskania specjalizacji przedstawionej w pracy autor posłużył się wiedzą płynącą z obserwacji 
rozgrywek na tej mapie. Jest to też jeden z wielu możliwych sposobów na pozyskiwanie reguł 
decyzyjnych, np. możliwe jest zastosowanie technik uczenia maszynowego w celu pozyskania 
takich reguł. 

Postawiony w ramach pracy warunek możliwości praktycznego zastosowania rozważanego 
algorytmu został spełniony, ponieważ badania prowadzone były na serwerach publicznie 
dostępnych dla graczy. Mogli oni bez żadnych widocznych opóźnień uczestniczyć w rozgrywce 
z botami «Bot. Do gry nie były potrzebne maszyny, które potrzebowałby znacznie więcej mocy 
obliczeniowej niż w przypadku publicznie dostępnych botów. 

Zaletą praktyczną opracowanej metodyki jest to, że zmiana zachowania botów nie wymaga 
rekompilacji jego kodu źródłowego. Wspomaga to możliwość szybkiego wprowadzania zmian 
w działaniu bota. Możliwa jest nawet jego zmiana bez restartowania gry. Taka funkcja jest 
przydatna przy prototypowaniu zachowania botów lub w sytuacjach kiedy opis zachowania 
bota może być ładowany dynamicznie podczas gry. Plansze w grze Counter-Strike są zasobami 
ładowanymi dynamicznie, więc ewentualna specjalizacja zachowania botów działających na 
planszy, również musi być ładowana dynamicznie. 

Potencjalne kierunki rozwoju pracy obejmują wykorzystanie algorytmów uczenia 
maszynowego w celu generowania reguł zachowania botów na planszy. Innym pomysłem jest 


próba adaptacji architektury do innych gier FPS. W wyniku czego mogą powstać ogólne reguły 
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grania w gry FPS lub boty uczące się grania w daną gre FPS zaczynając od jedynie ogólnego 


zestawu reguł postępowania. 
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